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CHAPTER 
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INTRODUCTION 


\ 


This  Validation  Sunnary  Raport '  describes  the  extent  to  vhich  a 
specific  Ada  compiler  conforms  to  the  Ada  Standard,  ANSI/MIL-STD>1815A. 
This  report  explains  all  technical  terms  used  vithin  it  and  thoroughly 
reports  the  results  of  ta^j^ing  this  compiler  using  the  Ada  Compiler 
Validation  Capability  ^c^V^  An  Ada  compiler  must  be  implemented 
according  to  the  Ada  Standard,  and  any  implementation-dependent  featxires 
must  conform  to  the  requirements  of  the  Ada  Standard.  The  Ada  Standard 
must  be  implemented  in  its  entirety,  and  nothing  can  be  implemented  that  is 
not  in  the  Standard.  \ 


c 


Sven  though  all  validated  Ada  compilers  conform  to  the  Ada  Standard,  it 
must  be  understood  that  some  differences  do  exist  between  implementations. 
The  Ada  Standard  permits  some  implementation  dependencies— for  example,  the 
maximum  length  of  identifiers  or  the  maximum  values  of  Integer  types. 
Other  differences  between  compilers  result  from  the  characteristics  of 
particular  operating  systems,  hardware,  or  implementation  strategies.  All 
the  dependencies  observed  during  the  process  of  testing  this  compiler  are 

<n  thlg  ranort. 


The  information  in  this  report  is  derived  from  the  test  results  produced 
during  validation  testing.  The  validation  process  includes  submitting  a 
suite  of  standardized  tests,  the  ACVC,  as  inputs  to  an  Ada  compiler  and 
evaluating  the  results.^The  purpose  of  validating  is  to  ensure  conformity 
of  the  compiler  to  the  A^a  Standard  by  testing  that  the  compiler  properly 
implements  legal  language  constructs  and  that  it  identifies  and  rejects 
illegal  language  constructs*  The  testing  also  identifies  behavior  that  is 
implementation-dependent  bxk  is  permitted  by  the  Ada  Standard.  Six  classes 
of  tests  are  used.  TheseXtests  are  designed  to  perform  checks  at  compile 
time,  at  link  time,  and  during  execution. 
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INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the 
Ada  Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83] 
using  the  current  Ada  Compiler  Validation  Capability  (ACVC) .  This 
Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of 
this  Ada  implementation.  For  any  technical  terms  used  in  this 
report,  the  reader  is  referred  to  [Pro90].  A  detailed  description 
of  the  ACVC  may  be  found  in  the  current  ACVC  User's  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the 
Ada  Certification  Body  may  make  full  and  free  public  disclosure  of 
this  report.  In  the  United  States,  this  is  provided  in  accordance 
with  the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results 
of  this  validation  apply  only  to  the  computers,  operating  systems, 
and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report 
do  not  represent  or  warrant  that  all  statements  set  forth  in  this 
report  are  accurate  and  complete,  or  that  the  siibject 
implementation  has  no  nonconformities  to  the  Ada  Standard  other 
than  those  presented.  Copies  of  this  report  are  available  to  the 
public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results 
should  be  directed  to  the  AVF  which  performed  this  validation  or 
to: 


Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 
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[Pro90]  Ada  Compiler  Validation  Procedures.  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 


[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June 
1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC. 
The  ACVC  contains  a  collection  of  test  programs  structured  into  six 
test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test 
name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and 
E  tests  are  executable.  Class  B  and  class  L  tests  are  expected  to 
produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and 
produce  a  PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the 
result  when  they  are  executed.  Three  Ada  library  units,  the 
packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used 
for  this  purpose.  The  package  REPORT  also  provides  a  set  of 
identity  functions  used  to  defeat  some  compiler  optimizations 
allowed  by  the  Ada  Standard  that  would  circximvent  a  test  objective. 
The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada 
Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents 
of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14 
of  the  Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is 
checked  by  a  set  of  executable  tests.  If  these  units  are  not 
operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage. 
Class  B  tests  are  not  executable.  Each  test  in  this  class  is 
compiled  and  the  resulting  compilation  listing  is  examined  to 
verify  that  all  violations  of  the  Ada  Standard  are  detected.  Some 
of  the  class  B  tests  contain  legal  Ada  code  which  must  not  be 
flagged  illegal  by  the  compiler.  This  behavior  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects 
violation  of  the  Ada  Standard  involving  multiple,  separately 
compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted . 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be 
replaced  by  implementation-specific  values  —  for  example,  the 
largest  integer.  A  list  of  the  values  used  for  this  implementation 
is  provided  in  Appendix  A.  In  addition  to  these  anticipated  test 
modifications,  additional  changes  may  be  rec[uired  to  remove 
unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this 
implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by 
the  AVF.  This  customization  consists  of  making  the  modifications 
described  in  the  preceding  paragraph,  removing  withdrawn  tests  (see 
section  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2 
and  [UG89]) . 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each 
test  of  the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that  have  to 

be  added  to  a  given  host  and  target  computer 
system  to  allow  transformation  of  Ada  programs 
into  executable  form  and  execution  thereof. 


Ada  Compiler 
Validation 
Capability 
(ACVC) 


The  means  for  testing  compliance  of  Ada 
implementations.  Validation  consisting  of  the 
test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  template  for 
the  validation  summary  (ACVC)  report. 


Ada  An  Ada  compiler  with  its  host  computer  system  and 

Implementation  its  target  computer  system. 


Ada  Joint  The  part  of  the  certification  body  which  provides 

Program  policy  and  guidance  for  the  Ada  certification  Office 

(AJPO)  system. 

Ada  The  part  of  the  certification  body  which  carries 

Validation  out  the  procedures  required  to  establish  the 

Facility  (AVF)  compliance  of  an  Ada  implementation. 

Ada  The  part  of  the  certification  body  that  provides 

Validation  technical  guidance  for  operations  of  the  Ada 
Organization  certification  system. 

(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC 
an  Ada  version. 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more 

System  computers  and  associated  software,  that  uses 

common  storage  for  all  or  part  of  a  program  and 
also  for  all  or  part  of  the  data  necessary  for 
the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 


ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 


arithmetic  operations  and  logic  operations;  and 
that  can  execute  programs  that  modify  themselves 
during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several 
inter-connected  units. 

Fulfillment  by  a  product,  process  or  service  of 
all  requirements  specified. 

An  individual  or  corporate  entity  who  enters  into 
an  agreement  with  an  AVF  which  specifies  the  terms 
and  conditions  for  AVF  services  (of  any  kind)  to 
be  performed. 

A  formal  statement  from  a  customer  assuring  that 
conformity  is  realized  or  attainable  on  the  Ada 
implementation  for  which  validation  status  is 
realized. 

A  computer  system  where  Ada  source  programs  are 
transformed  into  executable  form. 

A  test  that  contains  one  or  more  test  objectives 
found  to  be  irrelevant  for  the  given  Ada 
implementation . 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual, 
published  as  ANSI/MIL-STD-1815A-1983  and  ISO 
8652-1987.  Citations  from  the  LRM  take  the  form 
"<section> . <subsection> ; <paragraph> . " 

Software  that  controls  the  execution  of  programs 
and  that  provides  services  such  as  resource 
allocation,  scheduling,  input/ output  control, 
and  data  management.  Usually,  operating  systems 
are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada 
programs  are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated 
successfully  either  by  AVF  testing  or  by 
registration  [Pro90]. 
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Validation 


Withdrawn 

test 


The  process  of  checking  the  conformity  of  an  Ada 
compiler  to  rhe  Ada  programming  language  and  of 
issuing  a  certificate  for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in 
conformity  testing.  A  test  may  be  incorrect 
because  it  has  an  invalid  test  objective,  fails 
to  meet  its  test  objective,  or  contains  erroneous 
or  illegal  use  of  the  Ada  programming  language. 
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CHAPTER  2 


IMPr^MENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

Some  tests  are  withdrawn  by  the  AVO  from  the  ACVC  because  they  do 
not  conform  to  the  Ada  Standard.  The  following  95  tests  had  been 
withdrawn  by  the  Ada  Validation  Organization  (AVO)  at  the  time  of 
validation  testing.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for 
this  list  of  withdrawn  tests  is  91-08-02. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B330266 

C83026A 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2 . 2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are 
irrelevant  for  a  given  Ada  implementation.  The  inapplicability 
criteria  for  some  tests  are  explained  in  documents  issued  by  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in 
the  format  Al-ddddd.  For  this  implementation,  the  following  tests 
were  determined  to  be  inapplicable  for  the  reasor._  inoicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 

The  following  201  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEM. MAX_DIGITS : 


C24113L.  .Y  (1.4  tests) 
C35706L. .Y  ^4  tests) 
C35708L. .Y  (14  tests) 
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C35705L..Y  (14  tests) 
C35707L. .Y  (14  tests) 
C35802L. .Z  (15  tests) 


C45241L. .Y  (14  tests) 
C45421L..Y  U4  tests) 
C45524L..Z  (15  tests) 
C45641L..Y  (14  tests) 

C24113I..K  (3  TESTS)  use  a  line 
exceeds  126  characters. 


C45321L. .Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 

C46012L. .Z  (15  tests) 

length  in  the  input  file  which 


The  following  20  tests  check  for  the  predefined  type  LONGINTEGER ; 
for  this  implementation,  there  is  no  such  type: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a 
predefined  integer  type  with  a  name  other  than  INTEGER, 
LONG_INTEGER ,  or  SHORT_INTEGER;  for  this  implementation,  there  is 
no  such  type. 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SHORT_FLOAT ;  for  this  implementation,  there  is  no  such  type. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with 
a  name  other  than  FLOAT,  L0NG_FL0AT,  or  SH0RT_FL0AT ;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations 
for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for 
this  implementation,  MAX_MANTISSA  is  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the 
base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  TRUE. 

C4A013B  contains  a  static  universal  real  expression  that  exceeds 
the  range  of  this  implementation's  largest  floating-point  type; 
this  expression  is  rejected  by  the  compiler. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than 
type  DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside 
the  range  of  type  DURATION;  for  this  implementation,  the  ranges  are 
the  same . 


CA2009C  and  CA2009F  check  whether  a  generic  unit  can  be 
instantiated  before  its  body  (and  any  of  its  subunits)  is  compiled; 
this  implementation  creates  a  dependence  on  generic  units  as 
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allowed  by  AI-00408  and  AI-00506  such  that  the  compilation  of  the 
generic  unit  oodies  makes  the  instantiating  units  obsolete.  (See 
section  2.3.) 

CD1009C  uses  a  representation  clause  specifying  a  non-default  size 
for  a  floating-point  type. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  TESTS),  AND  CD2A840  use 
representation  clauses  specifying  non-default  sizes  for  access 
types . 

The  tests  listed  in  the  following  table  check  that  USE_ERROR  is 
raised  if  the  given  file  operations  are  not  supported  for  the  given 
combination  of  mode  and  access  method;  this  implementation  supports 
these  operations. 


Test 

File  Operation  Mode 

File  Access  Method 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

TEXT  10 

CE3102I 

CREATE 

OUT  FILE 

TEXT  10 

CE3102J 

OPEN 

IN  FILE 

TEXT  10 

CE3102K 

OPEN 

OUT  FILE 

TEXT  10 

The  tests  listed  in  the  following  table  check  the  given  file 
operations  for  the  given  combination  of  mode  and  access  method; 
this  implementation  does  not  support  these  operations. 

Test  File  Operation  Mode  File  Access  Method 


CE2105A 

CE2105B 

CE3109A 


CREATE 

CREATE 

CREATE 


IN_FILE 
IN_FILE 
IN  FILE 


SEQUENTIAL_IO 
DIRECT_IO 
TEXT  10 


CE2203A  checks  that  WRITE  raises  USE_ERR0R  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 
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EE2401D  checks  whether  read,  write,  set_index,  index,  size,  and 
end_of_file  are  supported  for  direct  files  for  an  unconstrained 
array  type.  USEERROR  was  raised  for  direct  create.  The  maximum 
element  size  supported  for  DIRECT_IO  is  32K  bits. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 

CE3111B  and  CE3115A  associate  multiple  internal  text  files  with  the 
same  external  file  and  attempt  to  read  from  one  file  what  was 
written  to  the  other,  which  is  assumed  to  be  immediately  available; 
this  implementation  buffers  output.  (See  section  2.3.) 

CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise 
USEERROR  if  they  specify  an  inappropriate  value  for  the  external 
file;  there  are  no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  IiAYOUT_ERROR  when  the  value  of  the 
page  number  exceeds  COUNT 'LAST;  for  this  implementation,  the  value 
of  COUNT 'LAST  is  greater  than  150000,  making  the  checking  of  this 
objective  impractical. 


2 . 3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  recjuired  for  78  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in 
the  way  expected  by  the  original  tests. 


B22003A 

B26001A 

B26002A 

B26005A 

B28003A 

B29001A 

B333Q1B 

B35101A 

B37106A 

B37301B 

B37302A 

B38003A 

B38003B 

B380CSA 

B38009B 

B55A01A 

B61001C 

B61001F 

B61001H 

B61001I 

BSLOGGM 

B61001R 

B61001W 

B67001H 

B83A07A 

B83A07B 

B83A07C 

wnmir 

B83E01D 

B83E01E 

B85001D 

B85008D 

B91001A 

B91002A 

E910Q2B 

B91002C 

B91002D 

B91002E 

B91002F 

B91002G 

B91002H 

E910G2I 

B91002J 

B91002K 

B91002L 

B95030A 

B95061A 

B95061F 

EB6061G 

B95077A 

B97103E 

B97104G 

BAIOOIA 

BAllOlB 

BC1109A 

BC11D9C 

BC1109D 

BC1202A 

BC1202F 

BC1202G 

BE2210A 

BE2413A 

C83030C  and  C86007A  were  graded  passed  by  Test  Modification  as 
directed  by  the  AVO.  These  tests  were  modified  by  inserting 
"PRAGMA  ELABORATE  (REPORT) ;"  before  the  package  declarations  at 
lines  13  and  11,  respectively.  Without  the  pragma,  the  packages 
may  be  elaborated  prior  to  package  Report's  body,  and  thus  the 
packages'  calls  to  function  REPORT. I DENT_INT  at  lines  14  and  13, 
respectively,  will  raise  PROGRAMERROR . 
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C85006C  was  graded  passed  by  Processing  Modification  as  directed  by 
the  AVO.  This  test  contains  a  task  that  is  too  large  to  be 
processed  with  the  default  task  stack  size  of  2048.  Therefore,  a 
task  stack  size  of  3300  was  specified  with  the  linker  option  "-D 
3300. 

CA2009C  and  CA2009F  were  graded  inapplicable  by  Evaluation 
Modification  as  directed  by  the  AVO.  These  tests  contain 
instantiations  of  a  generic  unit  prior  to  the  compilation  of  that 
unit's  body;  as  allowed  by  AI-00408  and  AI-00506,  the  compilation 
of  the  generic  unit  bodies  makes  the  compilation  unit  that  contains 
the  instantiations  obsolete. 

BC3204C  and  BC3205D  were  graded  passed  by  Processing  Modification 
as  directed  by  the  AVO.  These  tests  check  that  instantiations  of 
generic  units  with  unconstrained  types  as  generic  actual  parameters 
are  illegal  if  the  generic  bodies  contain  uses  of  the  types  that 
require  a  constraint.  However,  the  generic  bodies  are  compiled 
after  the  units  that  contain  the  instantiations,  and  this 
implementation  creates  a  dependence  of  the  instantiating  units  on 
the  generic  units  as  allowed  by  AI-00408  and  AI-00506  such  that  the 
compilation  of  the  generic  bodies  makes  the  instantiating  units 
obsolete — no  errors  are  detected.  The  processing  of  these  tests 
was  modified  by  re-compiling  the  obsolete  units;  all  intended 
errors  were  then  detected  by  the  compiler. 

AD8011A,  BD8001A,  BD8003A,  BD8004A,  &  BD8004B  were  graded  passed  by 
Test  Modification  as  directed  by  the  AVO.  These  tests  are 
applicable  to  implementations  that  support  package  MACHINE_CODE : 
the  Class  A  test  checks  that  a  machine-code  procdure  can  be 
compiled  and  called;  the  Class  B  tests  check  that  compilation  units 
are  illegal  if  various  conditions  for  the  use  of  code  statements 
are  violated.  This  implementation  requires  that  the 
implementation-defined  pragma  ABSTRACT_ACODE_INSERTIONS (TRUE)  be 
inserted  into  the  declarative  part  of  each  procedure  that  contains 
code  statements;  without  this  pragma,  the  compiler  rejects  the 
units  at  their  context  clause  for  package  MACHINE_CODE  (which  is 
the  behavior  expected  for  an  inapplicable  grade) .  This 
implementation  requires  the  pragma  as  an  enabling  device  for  the 
particular  "A-code"  machine  instructions,  in  anticipation  of  the 
intended  future  provision  of  a  second  type  of  machine-code 
instructions. 

CE3111B  and  CE3115A  were  graded  inapplicable  by  Evaluation 
Modification  as  directed  by  the  AVO.  The  tests  assume  that  output 
from  one  internal  file  is  unbuffered  and  may  be  immediately  read  by 
another  file  that  shares  the  same  external  file.  This 
implementation  raises  END_ERROR  on  the  attempts  to  read  at  lines  87 
and  101,  respectively. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 


The  testing  environment  consisted  of  a  host  computer,  a  target 
computer  and  two  auxiliary  computers.  The  host  computer  and  the 
Sun-3/260  auxiliary  computer  are  connected  by  Ethernet.  The  target 
computer  and  the  EWS4800/220  auxiliary  computer  are  connected  via 
3.5  inch  floppy  disks  and  by  a  RS232C  line.  The  configurations  of 
these  computers  are  described  by  the  following: 


Host  Computer  System: 
Auxiliary  Computer  System: 

Target  Computer  System: 
Auxiliary  Computer  System: 

Communication  link: 


EWS4800/60  running  EWS-UX/V  R8.1 
Sun-3/260  running  SunOS,  Version 
4.0.1 

MV4000  running  RX-UX832  VI. 6 
EWS4800/220  running  EWS-UX/V 
(Rel4.0),  Release  2.1 
Ethernet,  RS232C,  3.5  inch  floppy 

disks 


For  technical  and  sales  information  about  this  Ada  implementation, 
contact : 


Dr.  Toshio  Miyachi 
Environment  System  Department 
C  &  C  Common  Software  Development  Laboratory 
NEC  Corporation 

Shibaura  2-11-5,  Minato-ku,  Tokyo,  108  Japan 
VOICE  TELEPHONE:  81-3-5476-1107 
FAX  TELEPHONE:  81-3-5476-1113 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer's 
site  by  a  validation  team  from  the  AVF. 

3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes 
each  test  of  the  customized  test  suite  in  accordance  with  the  Ada 
Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC 
[Pro90] . 

For  all  processed  tests  (inapplicable  and  applicable) ,  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
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categories.  All  tests  were  processed,  except  those  that  were 
withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the 
implementation's  maximum  precision  (item  e;  see  section  2.2),  and 
those  that  depend  on  the  support  of  a  file  system  —  if  none  is 
supported  (item  d)  .  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 


a)  Total  Number  of  Applicable  Tests  3791 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  284 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  0 


f)  Total  Number  of  Inapplicable  Tests  284  (c+d+e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3 . 3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section 
1.3)  was  taken  on-site  by  the  validation  team  for  processing.  The 
customized  test  suite  was  loaded  onto  an  auxiliary  computer,  the 
Sun-3/260,  via  a  magnetic  tape  device.  The  customized  test  suite 
was  then  transferred  from  the  auxiliary  computer  to  the  host 
computer,  the  EWS4800/60,  using  UNIX  rsh  and  dd  commands  of  the 
host  computer  via  Ethernet. 

The  tests  were  compiled  and  linked  on  the  host  computer  system. 
The  executable  images,  generated  on  the  host  system,  were 
transferred  from  the  host  system  to  the  auxiliary  computer  system, 
EWS4800/220  via  Ethernet.  The  executable  images  were  then 
transferred  from  the  EWS4800/220  to  the  target  system  via  3.5  inch 
floppy  disks.  The  executable  images  were  executed  on  the  target 
system.  The  execution  results  were  transferred  from  the  target 
system  back  to  the  EWS4800/220  via  RS232C  communication  line.  The 
execution  results  were  then  transferred  from  the  EWS4800/220  to  the 
Sun- 3/2 60  by  Ethernet  where  they  were  then  captured  on  magnetic 
tape.  Commands  were  transferred  from  the  EWS4800/220  to  the  target 
system  via  RS232C  communication  line. 

Testing  was  performed  using  command  scripts  provided  by  the 
customer  and  reviewed  by  the  validation  team.  See  Appendix  B  for 
a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The 
compiler  options  invoked  both  explicitly  and  implicity  for 
validation  testing  during  this  test  were: 

-a  (for  A,  C  ,  D  and  E  tests  not  listed  below,  and  L 
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tests) 


-L  -a  (for  B,  tests,  support  files  and  the  following 
D  and  E  tests: 


D29002K  D64005E0M 

D64005ED  D64005EE 
D64005FB  D64005FC 
D64005FG  D64005FH 
E28002D  E28005D 

E52103Y  EB4011A 

ED2A26A  ED2A56A 
ED7002B  ED9002A) 


D64005EA 

D64005EF 

D64005FD 

D64005FI 

E28002B 

EB4012A 

ED4021A 


D64005EB  D64005EC 

D64005F0M  D64005FA 


D64005FE 

D64005FJ 

E43211B 

EB4014A 

ED4022B 


D64005FF 

E28002A 

E43212B 

ED1D04A 

ED4022C 


The  linker  options  invoked  explicitly  for  validation  testing  were: 
-D  3300  -a  (for  C85006C) 

-a  (for  all  other  tests) 

Test  output,  compiler  and  linker  listings,  and  job  logs  were 
captured  on  magnetic  tape  and  archived  at  the  AVF.  The  listings 
examined  on-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 


MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing 
the  ACVC.  The  meaning  and  purpose  of  these  parameters  are 
explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms 
of  the  maximum  input-line  length,  which  is  the  value  for 
$MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here  as 
Ada  string  aggregates,  where  "V”  represents  the  maximum  input-line 
length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN 

<126>  —  Value  of  V 

$BIG_ID1 

(1. .V-1  =>  'A',  V  =>  '1') 

$BIG_ID2 

(1. .V-1  =>  'A* ,  V  =>  *2') 

$BIG_ID3 

(1..V/2  =>  *A')  &  *3'  &  (1..V-1-V/2  => 

'A') 

$BIG_ID4 

(1..V/2  =>  'A*)  &  '4'  &  (1..V-1-V/2  => 

•A') 

$BIG_INT_LIT 

(1..V-3  =>  'O’)  &  "298" 

$BIG_REAL_LIT 

(1..V-5  =>  ’O')  &  "690.0" 

$BIG_STRING1 

&  (1. .V/2  =>  'A')  & 

$BIG_STRING2 

""  &  (1..V-1-V/2  =>  'A')  &  •!'  &  "" 

$ BLANKS 

(1. .V-20  =>  •  • ) 

$MAX_LEN_INT_BASED 

LITERAL 

“"2:"  &  (1..V-5  =>  '0')  &  "11;" 

$MAX_LEN_REAL_BASED_LITERAL 

"16:"  &  (1..V-7  =>  '0')  &  "F.E:" 

$MAX_STRING_LITERAL  ""  &  (1..V-2  =>  'A')  &  "" 
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The  following  table  contains  the  values  for  the  remaining  macro 
parameters . 

Macro  Parameter  Macro  Value 


$ACC_SIZE 

$ALIGNMENT 

$COUNT_LAST 

$  DE  FAULT_MEM_S I Z E 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRESS 1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$ FI LE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

$FORM_STRING 

$F0RM_STRING2 

$GREATER  THAN  DURATION 


32 

4 

2147483647 

2_097_152 

8 

V70_RXUX 

2#1.0#E-31 

16#40# 

16#80# 

161100# 

35 

•  I 

NO_SUCH_FIXED_TYPE 

NO_SUCH_TYPE 

••  II 

'•  CANNOT_RESTRI  CT_FI  LE_CAPACITY  •• 
75  000.0 


$GREATER  THAN  DURATION  BASE  LAST  131  073.0 


$GREATER  THAN  FLOAT  BASE  LAST  1.80141E+38 


$GREATER  THAN  FLOAT  SAFE  LARGE  1.0E308 


$GREATER_THAN_SHORT_FLOAT_SAFE_LARGE  1 . OE 3  0  8 
$HIGH  PRIORITY  255 
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$ILLEGAL  _EXTERNAL_FIIiE_NAMEl  /NODIRECTORY/FILENAME 

$ILLEGAL_EXTERNAL_FILE_NAME2 

••NAMES-OF-MORE-THAN-14-CHARACTERS 
"NAMES-OF-MORE-THAN- 14 -CHARACTERS 
"NAMES -OF-MORE-THAN- 14 -CHARACTERS 
"NAMES-OF-MORE-THAN- 14 -CHARACTERS 
"NAMES-OF-MORE-THAN- 14 -CHARACTERS 
"NAMES-OF-MORE-THAN-14-CHARACTERS 
"NAMES-OF-MORE-THAN- 14 -CHARACTERS 
"NAMES-OF-MORE-THAN- 14 -CHARACTERS 
"NAMES-OF-MORE-THAN-14-CHARACTERS 

$INAPPROPRIATE_LINE_LENGTH  -1 

$ INAPPROPRIATE  PAGE  LENGTH  -1 


$ INCLUDE_PRAGMA1 
$ INCLUDE_PRAGMA2 
$INTEGER_FIRST 
$INTEGER_LAST 
$ INTEGER_LAST_PLUS_1 
$ INTERFACE_LANGUAGE 
$LESS  THAN  DURATION 


PRAGMA  INCLUDE  ("A28006D1.TST") 
PRAGMA  INCLUDE  ( "B28006E1 . TST" ) 


-2147483648 


2147483647 


2  147  483  648 


AS,  C 
-75  000.0 


$LESS  THAN  DURATION  BASE  FIRST  -131  073.0 


$LINE_TERMINATOR 
$LOW  PRIORITY 


character ' val ( 10 ) 


$MACHINE_CODE_STATEMENT 

AA_INSTR ' { AA_EXIT_SUBPRGRM ,0,0,0, AA_INSTR_INTG ' FIRST , 0 ) ; 


$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN  INT 


AA  INSTR 


2147483647 


2  147  483  648 


-2147483648 
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$NAME 

NO_SUCH_T YPE_AVAI LABLE 

$NAME_LIST 

V70_RXUX 

$NAME_SPECIFICATI0N1 

/X2120A 

$NAME_SPECIFICATI0N2 

/X2120B 

$NAME_SPECIFICATI0N3 

/X3119A 

$NEG_BASED_INT 

16#F000000E# 

$NEW_MEM_SIZE 

2_097_152 

$NEW_STOR_UNIT 

8 

$NEW_SYS_NAME 

V70_RXUX 

$PAGE_TERMINATOR 

ASCII. FF 

$RECORD  DEFINITION 

RECORD 

instr_no  :  aa_instr_intg ; 
argO  :  aa_instr_intg ; 
argl  :  aa  instr  intg; 

arg2  :  aa_instr_intg ; 

arg3  :  aa  instr  intg; 

arg4  :  aa  instr  intg; 

END  RECORD; 

$RECORD_NAME 

aa_instr 

$TASK_SIZE 

32 

$TAS  K_STORAGE_S I Z E 

2048 

$TICK 

0.001 

$VARIABLE_ADDRESS  system 

.  address (16#d000_0000#-16#10000_0000#) 

$VARIABLE_ADDRESS1  system. 

address (16#d000_0004#-16#10000_0000#) 

$VARIABLE_ADDRESS2  system. 

address (16#d000_0008#-16#10000_0000#) 

$YOUR_PRAGMA 

PH YS I CAL_ADDRES S 
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COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 
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1  Options  and  Commands  of  The  PLU 

The  Program  Library  Utility  (PLU)  of  NEC  Ada  Compilation  System  for 
EWS-UX/V  to  V70/RX-UX832  is  an  interactive  program  that  enables  the 
user  to  manipulate  libraries  and  their  contents.  Commands  are  provided  for 
creating  and  deleting  both  root-libraries  and  sublibraries.  Library  contents 
such  as  directory  information,  and  declarative  information  about  exported 
symbols  within  compilation  units  can  be  displayed.  Compilation  units  can 
be  locked  to  prevent  unwanted  recompilation  or  deletion. 

1.1  The  Invocation  Command 

The  PLU  is  invoked  by  entering  the  following  commands  to  the  shell: 


apluv70  {<option>}  [<unit  — specif ier>] 

1.  Options 

The  following  options  are  permitted: 

—  a  <  file  — speO 

If  this  option  is  given,  the  PLU  will  attempt  to  open  the  subli¬ 
brary  given  by  <file— speo.  If  the  qualifier  is  not  present,  the 
default  is  the  sublibrary  designated  by  the  enviroarnem  variable 
”ADA_LIBRARy”.  If  the  variable  does  not  exist,  the  file  ADA_LIBRARY 
is  used. 

-s  LOCALl GLOBAL 

This  option  specifies  the  default  library  scope.  The  "LOCAL”  scope 
allows  operating  only  on  currently  open  sublibrary.  The  ’’GLOBAL” 
scope  allows  operating  on  all  sublibraries  in  the  program  library. 

The  default  scope  is  ’’LOCAL”.  Note  that  the  default  scope  can 
be  over-ridden  on  any  individual  commands  through  the  use  if 
explicit  ’’SCOPE”  option. 

—  c  <string> 

If  present,  this  option  causes  the  PLU  to  be  invoked  in  a  non— interactive 
mode,  where  the  single  command  included  in  the  <string>  will 
be  executed,  after  which  the  PLU  will  be  exit.  This  option  is 
convenient  within  shell  scripts  and  background  processes. 


1  OPTIONS  AND  COMMANDS  OF  THE  PLU 


2 


2.  Parameters 

The  PLU  takes  a  single,  optional  parameter,  that  specifies  the  default 
compilation  unit  to  be  operated  on.  The  <unit  — specif  ier>  can  be 
any  fully  qualified  (i.e.  Ada  syntax)  compilation— unit  name. 

To  obtain  information  about  a  specific  unit  (e.g.  the  names  and  struc¬ 
ture  of  the  types  exported  by  the  unit)  the  PLU  should  be  invoked  with 
the  name  as  a  parameter.  The  PLU  commands  will  then  by  default  op¬ 
erate  on  that  unit.  This  parameter  is  most  useful  in  conjunction  with 
the  ’’LIST”  command  and  its  use  will  be  described  more  fully  in  the 
section  describing  that  command. 

1.2  PLU  Commands 

Once  invoked  (unless  the  c”  option  is  given),  the  PLU  issues  the  prompt: 
PLU> 

after  which  the  user  can  enter  any  PLU  commands,  terminated  by  a  carriage 
return.  The  following  PLU  commands  are  currently  available: 

CREATE  —  Creates  a  sublibrary,  or  root  library. 

DELETE  —  Deletes  the  specified  units  or  the  current  sublibrary. 

DEPENDENCIES  —  Shows  the  dependencies  of  the  specified  compilation  units. 

DIRECTORY  —  Displays  information  about  specified  compilation  units. 

EXIT  —  Exits  the  PLU  session. 

HELP  —  Displays  help  information  for  the  specified  command. 

LIBRARY  —  Shows/changes  the  current  program  library. 

LIST  —  Displays  symbolic  information  within  specified  units. 

LOCK  —  Locks  the  specified  compilation  units. 

LOGGING  —  Permits  logging  of  a  PLU  session  to  a  file. 

—  Same  as  EXIT. 


QUIT 
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SCOPE  —  Shows/changes  the  current  default  library  scope. 

SHOW  -  Same  as  DIRECTORY. 

TYPE  —  Types  source  texts  for  the  specified  units. 

UNIT  —  Shows/changes  the  current  default  unit  — name. 

UNLOCK  —  Unlocks  the  specified  compilation  units. 

VERSION  —  Shows  the  version  of  the  library. 

All  commands,  options  and  other  keywords  may  be  abbreviated  to  the 
shortest  unique  prefix  required  to  identify  them.  In  the  following,  this  iden¬ 
tification  will  be  written  in  capital  letters.  All  input  to  the  PLU  is  case 
sensitive. 

1.3  Unit  Masks 

Whenever  a  <unit-mask>  is  required  (e.g.  in  the  SHOW  command),  the 
name  specified  may  include  the  wildcard  characters  ”%”  and  (represent¬ 
ing  any  single  character,  or  any  (possibly  empty)  arbitrary  string,  respec¬ 
tively).  These  names  may  also  be  qualified  by  unit— name  prefixes,  separated 
by  the  character,  as  with  the  normal  Ada  subunit  naming  conventions. 
The  first  component  of  a  <;unit— mask>  may  be  an  integer,  representing  a 
unit— number.  For  example,  the  following  are  valid  <unit-mask>’s; 

23  —  The  unit  with  unit  number  23 

23.  JUNK  * - All  subunits  of  unit  23’s  JUNK  subunit 

UNIT-'/,'/,'/,  —  All  units  whose  names  are  8  characters  long, 

the  first  5  being  "UNIT.” 

*  —  All  units 

Each  of  the  following  sections  describe  the  PLU  commands  in  detail. 

1.4  Symbol  Masks 

When  using  the  list  command,  you  may  specify  a  symbol  mask.  Such  a  mask 
specifies  entities  in  the  usual  Ada  manner.  A  package  named  P  is  referred 
to  as  P,  and  any  identifiers  in  it  are  referenced  by  the  familiar  dot  notation. 
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For  instance  ”TEXT_IO”  denotes  the  package  TEXTJO,  and  ”TEXT_IO.*” 
denotes  all  identifiers  defined  in  TEXTJO. 

1.5  Command  Summary 

This  section  details  the  syntax  and  semantics  of  each  PLU  cornmaiul. 

1.5.1  CREATE 

1.  Command  syntax: 

Create  <sublibrary-name>  [<parent-library-name>] 

Creates  a  new  sublibrary  (or  root  library)  in  the  file  system. 

2.  Options 

(a)  —Size  =  <number-of_blocks> 

Specifies  the  number  of  blocks  initially  allocated  for  the  sublibrary 
in  512  byte  blocks.  The  size  given  here  is  only  an  initial  size.  The 
sublibrary  will  grow  as  required.  If  the  size  option  is  not  given, 
100  blocks  are  allocated  by  default. 

(b)  -ROot 

Root  specefies  that  the  library  created  will  be  a  copy  of  the  system 
root  sublibrary. 

3.  Parameters 

If  two  parameters  are  given,  the  second  parameter  must  be  the  name 
of  an  existing  sublibrary,  which  will  be  used  as  the  parent.  The  first 
parameter  is  the  name  of  the  created  (offspring)  sublibrary. 

If  only  one  parameter  is  given,  the  action  taken  depends  on  the  presence 
of  the  ’’-ROOT”  and  ’’-NEWJIOOT”  options. 

If  neither  of  these  (mutually  exclusive)  options  are  given,  the  created 
sublibrary  will  be  the  offspring  of  the  currently  open  sublibrary.  If 
one  of  the  ’’ROOT”  options  is  given,  the  sublibrary  is  created  as  a  root 
sublibrary.  In  any  case,  the  parameters  given  must  be  valid  filenames. 
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4.  Example 

PLU>  Create  my_library .alb  father. alb 

This  command  will  create  an  empty  sublibrary,  that  will  have  the  sub- 
library  father. alb  as  its  parent. 

1.5.2  DELETE 

1.  Command  syntax: 


DELete  [<unit-mask>] 

The  specified  library  units  are  deleted  from  the  current  sublibrary  (un¬ 
less  they  are  locked  —  see  the  ’’LOCK”  command).  Note  that  ’’-SCOPE” 
option  or  default  scope  is  not  appropriate  for  this  command  —  it  oper¬ 
ates  only  on  the  current  sublibrary  (see  the  ’’LIBRARY”  command). 

2.  Options 


(a)  — CONFirm 

If  this  option  is  given,  the  PLU  will  prompt  the  user  for  confirma¬ 
tion  before  deleting  each  unit. 

(b)  -BOdy 

If  this  option  is  given,  only  the  applicable  body  units  will  be 
deleted. 

(c)  —specification 

Both  the  specification  and  body  units  will  be  deleted. 

(d)  —Library 

This  option  indicates  that  the  entire  current  sublibrary  will  be 
deleted  (including  all  its  units).  The  <unit— mask>  parameter  is 
not  allowed  in  this  option. 
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3.  Parameters 

The  <unit— mask>  is  a  qualified,  Ada— format  unit— name,  potentially 
including  wild-card  characters  (see  note  at  end  of  section  1.3).  If  omit¬ 
ted,  the  default  unit  — mask  will  be  used  (see  the  "UNIT”  command). 

1.5.3  DEPENDENCIES 

1.  Command  syntax: 

DEPendecies  [<unit-inask>] 

Shows  the  dependencies  recorded  for  the  designated  units. 

2.  Options 

(a)  —specification 
(h)  -BDdy 

If  neither  of  these  options  are  specified,  they  are  both  active  by 
default.  If  only  one  is  specified,  the  other  is  inactive  by  default. 
The  options  specify  the  amount  of  information  displayed: 

•  if ’’  —  SPECIFICATION”  is  given,  dependencies  recorded  lor  the 
designated  declaration  units  are  displayed; 

•  if  ’’—BODY”  is  given,  dependencies  recorded  for  the  de.sigualed 
body  units  cire  displayed. 

(c)  -scope  =  LOCAL  I  GLOBAL 

This  option  determines  the  allowed  libraries  used  by  PLU  in  search¬ 
ing  for  the  units  specified  by  <unit— mask>.  ’’LOCAL"  allows 
searching  in  the  current  sublibrary,  and  ’’GLOBAL”  allows  search¬ 
ing  in  the  entire  current  library.  If  — SCope  is  omitted,  the  current 
default  scope  will  be  used  (see  the  ’’SCOPE”  command). 

3.  Parameters 

The  <unit— inask>  is  a  qualified,  Ada— format  unit  — name,  (see  section 
1.3)  If  omitted,  the  default  unit  — mask  will  be  used  (see  the  ’’UNIT” 
command). 
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1.5.4  DIRECTORY 

1.  Command  syntax: 

Directory  C<unit-maslc>] 

Displays  information  about  the  contents  of  a  sublibrary  (i.e.  its  units). 

2.  Synonyms: 

SHow 

3.  Options 

(a)  -scope  =  LOCAL  I  GLOBAL 

This  option  determines  the  allowed  libraries  used  by  the  PLU 
in  searching  for  the  units  specified  by  <uiiit— maskr>.  ’’LOCAL” 
allows  searching  in  the  current  sublibrary,  and  ’’GLOBAL”  allows 
searching  in  the  entire  current  library.  If  the  ’’  —  SCOPE”  option  is 
omitted,  the  current  default  scope  will  be  used  (see  the  ’’SCOPE” 
command). 

(b)  — subunits 

If  this  option  is  .given,  the  information  displayed  (recursively)  in¬ 
cludes  any  subunits  that  the  designated  units  may  have. 

(c)  — DEPendencies 

Specifies  that  the  information  displayed  shall  include  tlu*  deiJen- 
decies  recorded  for  the  selected  units. 

(d)  —Unit-id 

If  this  option  is  given,  the  unit— id  of  each  selected  unit  is  dis¬ 
played. 

(e)  — ATtributes 

Specifies  that  information  pertaining  to  the  attributes  of  the  se¬ 
lected  units  is  to  be  included. 

(f)  -BRief 

Gives  a  brief  list  of  the  specified  unit.  Only  one  line  per  units  is 
given. 
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(g)  —Since  =  <time> 

Only  the  units  that  are  compiled  after  the  given  time  are  dis¬ 
played. 

The  time  format  is  that  of  the  UNIX  time  specification,  e.g.  May 
3  12:30:21  1991. 

Data  may  be  omitted  from  the  right,  so  Jul  3  and  Jul  3  12:30 
are  examples  of  valid  time  specifications.  For  the  user’s  conve¬ 
nience,  the  pseudo  time  ’’TODAY”  is  valid,  with  the  obvious  seman¬ 
tics. 

(h)  — CONTainer 

Specifies  that  the  information  displayed  shall  include  the  names 
of  the  containers  assigned  to  the  selected  units. 

(i)  -ALl 

If  this  option  is  given,  all  available  information  on  the  selected 
units  is  displayed  (equivalent  to  giving  all  the  above  options  except 
BRIEF). 

4,  Parameters 

The  <unit— inask>  is  a  qualified,  Ada— format  unit  — name,  as  de¬ 
scribed  in  section  1.3.  If  omitted,  the  default  unit— mask  will  l>e  used 
(see  the  ’’UNIT”  command). 

Both  the  specification  and  corresponding  body  of  selected  units  will  be 
displayed  during  a  DIRECTORY  listing. 

1.5.5  EXIT 

1.  Command  syntax: 

EXIT 

Closes  the  current  library  and  the  log  file  (if  any),  and  terminates  the 
session. 

2.  Synonyms: 

Quit 
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1.5.6  HELP 

1.  Command  syntax: 

HELP  [<conimand>] 

Provides  explanation  of  the  PLU  commands.  If  < command >  is  not 
specified,  a  brief  summary  of  all  available  PLU  commands  will  be  dis¬ 
played.  Otherwise,  the  command  syntax  and  applicable  options  for  the 
specified  command  is  shown. 

1.5.7  LIBRARY 

1.  Command  syntax: 

LIBrary  [<library-name>] 

Selects  a  new  default  sublibrary,  or  displays  the  filenames  of  the  subli¬ 
braries  making  up  the  current  library. 

2.  Parameters 

The  <library— name>  is  a  valid  filename  of  the  sublibraries  making 
up  the  current  library  are  displayed. 

1.5.8  LIST 

1.  Command  syntax: 

List  [<synibol-mask>] 

This  very  powerful  command  displays  the  contents  of  the  symbol— table 
for  specified  units.  Using  wildcards  and  appropriate  options,  the  user 
can  determine  such  information  as  the  name  of  the  unit  where  a  par¬ 
ticular  declaration  occurs,  or  a  subroutine  parameter  profile. 


2.  Options 
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(a)  -scope  =  LOCAL  I  GLOBAL 

This  option  determines  where  the  PLU  searches  for  symbols  spec¬ 
ified  by  tt  <symbol— mask>.  LOCAL  restricts  the  search  to  tlie 
current  sublibrary,  GLOBAL  searches  the  entire  current  library.  If 
the  ’’  —  SCOPE”  option  is  omitted,  the  current  default  scope  will  be 
used  (see  the  SCOPE  command). 

It  is  advisable  to  restrict  the  search  space  for  the  LIST  command 
by  using  as  few  wildcards  as  possible,  and  by  using  local  scope  in 
order  to  minimize  the  the  amount  of  output  produced. 

(b)  -EntityJcind  =  (CONSTANT  I  VARIABLE  I  TYPE  I 
ENUMERATION-LITERAL  |  EXCEPTION  I  PROCEDURE  I 
FUNCTION  I  SUBPROGRAM  1  PACKAGE  I 

GENERIC  I  VALUE  I  PREDEFINED -OPERATOR  I  ALL) 

Entity-kind  can  be  used  to  limit  the  display  to  only  those  sym¬ 
bols  matching  the  ’entity— kind’  given.  This  is  useful,  both  to 
limit  the  amount  of  information  displayed,  and  to  limit  the  search 
time.  This  option  can  also  be  used  to  reduce  ambiguity  when 
overloaded  names  are  encountered,  most  of  the  entity— kinds  cor¬ 
respond  to  .4da  style  terminology,  but  a  few  convenient  terms 
have  been  added,  such  as  VALUE  (corresponding  to  CONSTANT, 
VARIABLE,  ENUMERATION-LITERAL  or  FUNCTION).  The 
special  term  PREDEFINED-OPERATOR  displays  the  compiler 
generated  operators  that  are  created  for  each  user  —declared  nu¬ 
meric  type.  Only  explicitly  declared  operators  are  displayed  by 
default. 

(c)  -LINe 

The  source— file  line— number  of  each  symbol’s  declaration  will  be 
displayed  as  a  comment.  Note  that  these  line  numbers  are.  in 
some  cases,  approximate. 

(d)  — DEClaration 

An  Ada— like  declaration  of  the  symbol  will  be  displayed.  This  al¬ 
lows  display  of  field  names  in  record  types,  parameter  profiles  for 
subroutine  declaration,  and  other  useful  information.  The  dec¬ 
laration  is  as  much  like  a  normal  Ada  declaration  as  po.ssible. 
although  certain  kinds  of  information  (such  as  the  ordinal  value 
of  enumeration  literals)  are  displayed  in  non  — Ada  form. 
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3.  Parameters  The  tt  <symbol— mask>  is  qualified,  AdaJ'onnat  sym- 
bol_name.  The  Ada  notation  may  be  used,  both  to  specify  subunits 
and  local  declarative  items.  If  the  <symbol-mask>  begins  with  a 
character,  then  it  must  be  proceeded  by  the  default  unit— mask  (see 
the  ’’UNIT”  command).  The  following  are  examples  of  ways  to  specify 
the  PUT  procedures  in  FLOATJO: 

"TEXT.IO. FLOAT*. PUT" 

".PUT",  if  default  unit  is  TEXT_I0.FL0AT_I0 

1.5.9  LOCK 

1.  Command  syntax: 

LOCK  [<unit-mask>] 

Locks  the  specified  units  such  that  they  cannot  be  deleted  or  recom¬ 
piled  without  being  unlocked  first  (see  the  ’’UNLOCK”  command).  By 
default,  this  command  locks  the  specification,  the  corresponding  body 
and  its  subunits. 

2.  Options 

(a)  — CONFirm 

Prompts  for  confirmation  before  locking  each  unit. 

(b)  -BOdy 

The  applicable  specification  and  body  units  will  be  locked,  but 
not  the  subunits. 

(c)  —Specification 

Only  the  specification  units  will  be  locked. 

3.  Parameters 

The  <  unit— mask>  is  a  qualified,  Ada— format  unit  — name,  poten¬ 
tially  including  wild-card  characters  (see  note  at  end  of  section  1.3). 
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1.5.10  LOGGING 

1.  Command  syntax: 

LQGging  C<log-f ile-najne>] 

Allows  output  to  be  directed  to  a  log  file.  If  the  <log_f  ile_neune> 
parameter  is  omitted,  the  current  log  file  name  will  be  displayed. 

2.  Options 

(a)  -QFf 

Terminates  logging,  closing  the  current  log— file.  If  this  option  is 
given,  no  parameter  may  be  specified. 

1.5.11  QUIT 

1.  Command  syntax: 

Quit 

Quit  is  synonym  for  EXIT  and  pressing  <CTRL— D>.  Quit  closes  the  cur¬ 
rent  log  file  (if  there  is  any),  closes  the  current  library,  and  terminates 
the  PLU  session. 

1.5.12  SCOPE 

1.  Command  syntax: 

scope  [LOCAL  I  GLOBAL] 

Allows  setting  of  a  default  library  scope  for  the  various  PLU  commands 
such  as  the  List  command.  If  parameter  is  not  given,  the  current  default 
scope  is  displayed.  The  initial  default  scope  is  taken  from  the  command 
invocation  of  the  PLU. 

2.  Parameters 

The  parameter  determines  where  the  PLU  looks  for  units  specified  by 
<unit— mask>.  LOCAL  means  searching  in  the  current  sublibrary, 
and  GLOBAL  means  .searching  in  the  current  library. 
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1.5.13  SHOW 

1.  Command  syntax: 

SHOW  [<unit-mask>] 

This  i  a  synonym  for  Directory,  q.v. 

1.5.14  TYPE 

1.  Command  syntax: 

Type  [<unit-mask>] 

Allows  listing  of  the  source  texts  of  the  specified  units.  If  the  source— text 
for  a  specified  unit  is  not  contained  in  the  library,  the  following  message 
will  be  displayed: 

--  Mo  source  code  found  for  <unit-name> 

By  default,  only  the  specifications  of  specified  units  are  listed. 

2.  Options 

(a)  -LOg 

Will  cause  the  source— test  listing  to  be  directed  to  a  file  having 
the  name  <unit— name>_s .  ada  if  a  specification  is  being  listed, 
of  <unit— name  >-b.  ada  if  a  body  is  being  listed.  Files  will  be 
written  to  the  current  default  working  directory. 

(b)  —Specification 

Will  cause  the  specifications  of  the  designated  units  to  be  listed. 

(c)  —Body 

Will  cause  the  bodies  of  the  designated  units  to  be  listed. 

(d)  —Line 

Causes  line  numbers  to  be  placed  in  the  left  most  cohmuis  of  the 
listing. 
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(e)  -scope  =  LOCAL  t  GLOBAL 

This  option  determines  where  the  PLU  looks  for  the  units  spec¬ 
ified  by  <unit— mask>.  ’’LOCAL”  searches  in  the  current  subli¬ 
brary,  and  ’’GLOBAL”  searches  in  the  entire  current  library.  If  the 
’’  —  SCOPE”  option  is  omitted,  the  current  default  scope  will  be  used 
(see  the  ’’SCOPE"  command). 

3.  Parameters 

The  <unit— mask>  is  a  qualified,  Ada— format  unit  — name,  as  de¬ 
scribed  in  section  1.3.  If  omitted,  the  default  unit -mask  will  be  used 
(see  the  "UNIT”  command). 

1.5.15  UNIT 

1.  Command  syntax: 

UNIt  [<unit-mask>] 

Allows  setting  of  a  default  unit-mask  for  those  PLU  commands  that 
operate  on  units.  If  the  parameter  is  omitted,  the  current  default 
unit -mask  is  displayed.  The  initial  default  unit -mask  is  taken  from 
the  PLU  invocation  command  line. 

2.  Parameters 

The  <unit  -mask>  is  a  qualified,  Ada-format  unit-name,  as  dt 
scribed  in  Section  1.3. 

1.5.16  UNLOCK 

1.  Command  syntax: 

UNLock  [<unit-mask>] 

Unlocks  the  specified  units  so  that  they  can  be  delet  -d  or  recompiled. 
By  default,  this  command  unlocks  the  specification,  the  corresponding 
body  and  all  the  body’s  subunits. 


2.  Options 
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(a)  -CONFirm 

If  this  option  is  given,  the  PLU  will  prompt  for  confirmation  before 
unlocking  each  unit. 

(b)  —Body 

If  this  option  is  given,  only  the  body  and  subunits  are  unlocked. 

(c)  — subunit 

Only  the  subunits  are  unlocked. 

3.  Parameters 

The  <unit— mask>  is  a  qualified,  Ada— format  unit— name,  as  de¬ 
scribed  in  Section  1.3.  If  omitted,  the  default  unit  — mask  will  be  used 
(see  the  ’’UNIT”  command). 

1.5.17  VERSION 

1.  Command  syntax: 

Version 

Shows  the  version  of  the  compiler  which  was  used  to  compile  the  units 
in  the  current  library. 


2  Options  for  The  Ada  Compiler 

The  Ada  Compiler  is  invoked  by  specifying  a  call  of  the  program  .Ada  to  the 
shell.  The  invocation  command  is  described  in  Section  2.1. 

If  any  diagnostic  messages  are  produced  during  the  compilation,  they  are 
output  on  the  diagnostic  file  and  on  the  standard  output  .  The  diagnostic 
file  and  the  diagnostic  messages  are  described  in  Sections  2.1.3  and  2.3. 

The  user  may  request  additional  listings  to  be  output  on  a  list  file  by 
specifying  options  in  the  compiler  invocation.  The  list  file  and  the  listings 
are  described  in  Sections  2.1.2. 

The  compiler  uses  a  program  library  during  the  compilation.  The  com¬ 
pilation  unit  may  refer  to  units  from  the  program  and  will  be  showed  in  the 
program  library  as  a  result  of  a  successful  compilation.  The  program  library 
is  described  in  the  attachment.  Section  2.4  briefly  describes  how  the  Ada 
compiler  uses  the  library. 
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2.1  The  Invocation  Command 

The  invocation  command  has  the  following  syntax: 


adav70  <source— f ile— name>  {<source— f ile— name> } 


1.  Options 
— L  and  —1 

Causes  the  compiler  to  produce  a  formatted  listing  of  the  input 
sources.  The  listing  is  written  on  the  list  file.  S  -tioii  2. .1.2  con¬ 
tains  a  description  of  the  source  listing.  The  default  is  no  list  file, 
in  which  case  no  source  listing  is  produced,  regardless  of  any  LIST 
pragmas  in  the  program  or  any  diagnostic  messages  produced. 

—  X 

Causes  the  compiler  to  produce  a  cross-reference  listing.  If  this 
option  is  given  and  no  severe  or  fatal  errors  are  found  during  the 
compilation,  the  cross-reference  listing  will  be  written  on  the  list 
file.  The  default  excludes  cross-reference. 

-P 

Progress— report. 

—  a  <lib_spec> 

Specifies  the  current  sublibrary,  and  therefore  the  progi’ani  library. 
If  this  option  is  omitted  the  sublibrary  designated  by  the  environ¬ 
ment  variable  ADA_LIBRARY  is  used.  If  the  variable  does  not  e.xist 
the  file  ADA_LIBRARY  is  used.  Section  2.4  describes  how  the  .Ada 
compiler  uses  the  library. 

—  c  <file_narae> 

Specifies  the  corfiguration  file  to  be  used  by  the  compiler  in  the 
current  compilation.  If  this  option  is  omitted,  the  configuration 
file(config)  in  the  compiler  directory  is  used. 

—  s  and  — S 

Specifies  that  the  source  text  is  not  to  be  saved  in  the  program 
library.  This  saves  some  space  in  the  sublibrary.  The  default  is 
to  save  source  text.  In  this  way,  the  user  is  always  certain  what 
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version  of  the  source  text  was  compiled.  The  source  text  may  be 
displayed  from  the  sublibrary  with  the  PLU  Type  command. 

-B 

Build  standard.  Pseudo  compilation  of  package  standard.  This 
option  is  intended  for  maintenance  purposes  only. 

— n 

No  check.  Suppress  all  run-time  checks.  By  default,  all  run¬ 
time  checks  are  generated. 

— N  <keyword>  {,  <keyHord>} 

Toggle  check.  Selective  suppress  of  run-time  checks.  If  a  check  is 
suppressed,  the  option  will  enable  the  check.  If  a  check  is  enabled, 
the  option  wilt  .suppress  the  check.  The  following  keywords  are 
allowed: 

•  access 

•  index 

•  discriminant 

•  range 

•  length 

•  elaboration 

•  storage 

Keywords  are  case— insensitive  and  can  be  abbreviated  .such  that 
the  abbreviation  is  unique. 

— o 

Optimize.  Optimize  the  program  with  respect  to  e.xecution  time, 
which,  under  normal  circumstances,  also  is  optimization  with  re¬ 
spect  to  size  of  the  executable. 

— u  <unit_nuniber> 

Specifies  that  the  compilation  unit  being  compiled  is  assigned  t  he 
unit  number<unit_number>  in  the  current  sublibrary  (see  the  at¬ 
tachment  for  explanation  of  unit  numbers).  This  o])tion  will  only 
work  for: 

•  compilations  containing  a  single  compilation  unit  which  is  nei¬ 
ther  a  subunit  nor  contains  subunit  stubs. 
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•  unit  numbers  which  are  unused  and  smaller  than  32768. 

2.  Parameters 

The  <  source  — file— neime>  specifies  the  file  containing  the  source 
texts  to  be  compiled.  A  source  file  is  expected  to  have  the  string  ”  .  ada” 
as  the  last  four  characters  of  its  name.  If  the  last  part  of  the  name  does 
not  contain  ,  the  string  ”.ada”  is  appended  to  the  name  .  More 
than  one  file  name  must  be  specified. 

2.1.1  The  List  File 

The  name  of  the  list  file  is  identical  to  the  name  of  the  source  file  except 
that  the  final  characters  "  .ada”  are  replaced  by  ”  .lis”.  The  list  file  will  be 
placed  in  the  current  directory. 

2.1.2  The  Diagnostic  File 

The  name  of  diagnostic  file  is  identical  to  the  name  of  the  source  file  except 
that  the  final  characters  ”.ada”  are  replaced  by  ”  .err”.  The  diagnostic  file 
will  be  placed  in  the  invoker’s  current  directory. 

The  diagnostic  file  is  a  file  containing  a  list  of  diagnostic  messages,  each 
followed  by  a  line  showing  the  number  of  the  line  in  the  source  that  caused  the 
message  to  be  generated,  and  then  by  a  blank  line.  The  file  is  not  separated 
into  pages  and  there  are  no  headings. 

2.1.3  The  Configuration  File 

Certain  functional  characteristics  of  the  compiler  may  be  modified  t)v  the 
user.  These  characteristics  are  passed  to  the  compiler  by  means  of  a  config¬ 
uration  file,  which  is  a  text  file.  The  contents  of  the  configuration  file  must 
be  an  .Ada  positional  aggregate,  written  on  one  line,  of  the  type  CONFIGU- 
RATIONJRECORD,  which  is  described  below.  The  configuration  file  is  not 
accepted  by  the  compiler  in  the  following  cases: 

•  The  syntax  does  conform  with  the  syntax  for  positional  .Ada  aggregates. 

•  A  value  is  outside  the  ranges  specified  below. 

•  A  value  is  not  specified  as  a  literal. 
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•  LINES_PER_PAGE  is.  not  greater  then  TOP-MARGIN  +  BOTTOM-MARGIN. 

•  The  aggregate  occupies  more  than  one  line. 

If  the  compiler  is  unable  to  accept  the  configuration  file,  an  error  message 
is  written  on  the  standard  out  put  and  the  compilation  is  terminated. 

Type  OUTFORMATTING  is 
record 

LINES_PER_PAGE  :  INTEGER  range  30.. 100; 

—  cf .  Section  2.3.1 

TOP_MARGIN  :  INTEIGER  range  4 .  .  90 ; 

--  cf .  Section  2.3.1 

BOTTOM-MARGIN  :  INTEGER  range  0..90; 

—  cf.  Section  2.3.1 

OUT-LINELENGTH  ;  INTEGER  range  80.. 132; 

—  cf.  Section  2.3.1 
SUPPRESS-ERRORNO  :  BOOLEAN; 

--  cf.  Section  2.3.4 

end  record; 

Type  INPUT-FORMATS  is 
(ASCII) ; 

—  cf .  Section  2.2 

Type  INFORMATTING  is 
record 

INPUT-FORMAT  :  INPUT-FORMATS; 

—  cf .  Section  2.2 

INPUT-LINELENGTH  :  INTEGER  range  70.. 250; 

--  cf .  Section  2.2 
end  record; 

Type  CONFIGURATION-RECORD  is 
record 

IN-FORMAT  :  INFORMATTING ; 

OUT-FORMAT  :  OUTFORMATTING; 

ERROR-LIMIT  ;  INTEGER; 
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—  cf.  Section  2.3.4 
end  record; 

The  configuration  file  has  the  following  content: 

((ASCII,  126),  (48,  5,  3,  100,  FALSE),  200) 

The  name  of  this  configuration  file  is  passed  to  the  compiler  through  the  argu¬ 
ment  supplied  with  the  -c  option. 

The  output  formatting  parameters  have  the  following  meaning: 
LINES_PER_PAGE: 

specifies  the  maximum  number  of  lines  written  on  each  page  (including 
top  and  bottom  margin). 

T0P_MARGIN: 

specifies  the  number  of  lines  on  top  of  each  page  used  for  a  standard 
heading  and  blank  lines.  The  heading  is  placed  in  the  middle  lines  of 
the  top  margin. 

BOTTOM-MARGIN: 

specifies  the  minimum  number  of  lines  left  blank  in  the  bottom  of  the 
page.  The  number  of  lines  available  for  the  listing  of  the  program  is 
LINES.PERJP.AGE  -  TOP.MARGIN  -  BOTTOM.M.ARGIN. 

OUT-LINELENGTH: 

specifies  the  maximum  number  of  characters  written  on  eacli  line.  Lines 
longer  than  OUTXINELENGTH  are  separated  into  two  lines. 

SUPPRESS-ERRORNQ: 

specifies  the  format  of  error  messages. 

2.2  The  Source  Text 

The  user  submits  one  file  containing  a  source  text  in  each  compilation.  'I’he 
source  text  may  consist  of  one  or  more  compilation  units. 

The  format  of  the  source  text  specified  in  the  configuration  file  (cf.  Sec¬ 
tion  2.1.3)  must  be  the  ISO-FORMAT  .ASCII.  This  format  rec|uires  that  the 
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source  text  is  a  sequence  of  ISO  characters  (ISO  standard  646),  wlieie  each 
line  is  terminated  by  either  one  of  the  following  termination  seciuences  (CR 
means  carriage  return,  VT  means  vertical  tabulation,  LF  means  line  teed,  and 
FF  means  form  feed): 

•  A  sequence  of  one  or  more  CRs,  where  the  sequence  is  neither  immedi¬ 
ately  preceded  nor  immediately  followed  by  any  of  the  characters  VT, 
LF,  or  FF. 

•  Any  of  the  characters  VT,  LF,  or  FF,  immediately  preceded  and  followed 
by  a  sequence  of  zero  or  more  CRs. 

In  general,  ISO  control  characters  are  not  permitted  in  the  source  text  with 
the  following  exceptions: 

•  The  horizontal  tabulation  (HT)  character  may  ue  used  as  a  separator 
between  lexical  units. 

•  LF,  VT,  FF,  and  CR  mri.y  be  used  to  terminate  lines,  as  described  above. 

The  maximum  number  of  characters  in  an  input  line  is  determined  by  the 
contents  of  the  configuration  file,  cf.  Section  2.1.3.  The  control  characters 
CR,  VT,  LF,  and  FF  are  not  considered  a  part  of  the  line.  Lines  containing 
more  than  the  maximum  number  of  characters  are  truncated,  and  an  error 
message  is  issued. 

2.0  Compiler  Output 

The  compiler  may  produce  output  in  the  list  file,  the  diagnostic  file  and  the 
standard  output.  It  furthermore  updates  the  program  library  if  the  compila¬ 
tion  is  successful.  The  present  section  describes  the  text  output  in  the  three 
files  mentioned  above.  The  updating  of  the  program  library  is  described  in 
section  2.4. 

The  compiler  may  produce  the  following  text  output: 

1.  A  listing  of  the  source  text  with  embedded  diagnostic  messages  is  writ¬ 
ten  on  the  list  file  if  the  -L  option  is  present. 

2.  A  compilation  summary  is  written  in  the  list  file  if  the  -L  t)|)tion  is 
present. 
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3.  A  cross- refp fence  listing  is  written  on  the  list  file  if  the  -x  option  is 
present  and  severe  or  fatal  errors  have  been  detected  during  the  com¬ 
pilation. 

4.  If  there  are  any  diagnostic  messages,  a  diagnostic  file  containing  the 
diagnostic  messages  is  written. 

5.  Diagnostic  messages  other  than  warnings  are  written  on  the  standard 
output. 

2.3.1  Format  of  the  List  File 

The  list  file  may  include  one  or  more  of  the  following  parts;  a  source  listing, 
a  cross-reference  listing  and  a  compilation  summary. 

The  parts  of  the  list  file  are  separated  by  page  ejects.  The  contents  of 
each  part  are  described  in  sections  2.3.2.  -  2.3.3. 

The  format  of  the  output  on  the  list  file  is  controlled  by  the  configuration 
file  (cf.  Section  2.1.3)  and  may  therefore  be  controlled  by  the  user. 

2.3.2  Source  Listing 

A  source  listing  an  unmodified  copy  of  (pars  of)  the  source  text.  The  listing 
is  divided  into  pages  and  each  line  is  supplied  with  a  line  number. 

The  number  of  lines  output  in  the  source  listing  is  governed  by  t  he  oc¬ 
currence  of  LIST  pragmas  and  the  number  of  objectionable  lines. 

•  Parts  of  the  listing  can  be  suppressed  by  the  use  of  LIST  in  agmas.  and 
page  breaks  may  be  introduced  by  PAGE  pragmas. 

•  A  line  containing  a  construct  that  caused  a  diagnostic  message  is  lu  inted 
even  if  it  occurs  at  a  point  where  the  listing  has  been  suppressed  by  a 
LIST  pragma. 

2.3.3  Compilation  Summary 

At  the  end  of  a  compilation,  the  compiler  produces  a  summary  that  is  an 
output  on  the  list  file  if  the  -L  option  is  present. 

The  summary  contains  information  about: 
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1.  The  type  and  name  of  the  compilation  unit,  and  whether  it  has  been 
compiled  successfully  or  not. 

2.  The  number  of  diagnostic  messages  produced  for  each  class  of  severity, 
rf  Section  2.3.4. 

3.  Which  options  were  present. 

4.  The  full  name  of  the  source  file. 

5.  The  full  name  of  the  program  library. 

6.  The  number  of  source  text  lines. 

7.  The  size  of  the  text  segment,  the  data  segment,  and  the  BSS  segment. 

8.  Elapsed  time  and  CPU  time. 

9.  A  ’’Compilation  terminated”  message  if  the  compilation  unit  was  the 
last  in  the  compilation  or  ’’Compilation  of  next  unit  initiated’'  other¬ 
wise. 

2.3.4  Diagnostic  Messages 

The  Ada  compiler  issues  diagnostic  messages  on  the  diagnostic  file  (cf.  Sec¬ 
tion  2.1.2).  Diagnostics  other  than  warnings  also  appear  on  the  standard 
output.  If  a  source  text  listing  is  required,  the  diagnostics  are  also  found 
embedded  in  the  list  file  (cf.  Section  2.1.1). 

In  a  source  listing  ,  a  diagnostic  message  is  placed  immediately  after  the 
source  line  causing  the  message.  Messages  not  related  to  any  particular  line 
are  placed  at  the  top  of  the  listing.  Every  diagnostic  message  in  the  diagnostic 
file  is  followed  by  a  line  stating  the  line  number  of  the  objectional  line.  The 
lines  are  ordered  by  increasing  source  line  numbers.  Messages  not  related 
to  any  particular  line  are  assigned  to  line  0.  On  the  standard  output  the 
messages  appear  in  the  order  in  which  they  are  generated  by  the  compiler. 

The  diagnostic  messages  are  classified  according  to  their  severity  and  the 
compiler  action  taken; 
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Warning:  Reports  a  questionable  construct  or  an  error  that  does  not  influ¬ 
ence  the  meaning  of  the  program.  Warnings  do  not  hinder  the  genera¬ 
tion  of  object  code. 

Example:  A  warning  will  be  issued  for  constructs  for  which  the  compiler 
detects  that  they  will  raise  CONSTRAINT-ERROR  at  run  time. 

Error:  Reports  an  illegal  construct  in  the  source  program.  Compilation 
continues,  but  no  object  code  will  be  generated. 

Example:  most  syntax  errors;  most  static  semantic  errors. 

Severe  error:  Reports  an  error  which  causes  the  compilation  to  be  termi¬ 
nated  immediately.  No  object  code  is  generated.  Example:  .4  severe 
error  message  will  be  issued  if  a  library  unit  mentioned  l)y  a  WITfl 
clause  is  not  present  in  the  current  program  library. 

Fatal  error:  Reports  an  error  in  the  compiler  system  itself.  The  compila¬ 
tion  is  terminated  immediately  and  no  object  code  is  produced.  The 
user  may  be  able  to  circumvent  a  fatal  error  by  correcting  the  program 
or  by  replacing  program  constructs  with  alternatives.  Please  inform 
NEC  about  the  occurrence  of  fatal  errors. 

The  detection  of  more  errors  than  allowed  by  the  number  specifled  by  the 
ERROR-LIMIT  parameter  of  the  configuration  file  (cf.  Section  2.1.3)  is 
considered  a  severe  error. 

2.4  The  Program  Library 

This  section  briefly  describes  how  the  Ada  compiler  changes  the  program 
library.  For  a  general  general  description  of  the  program  library  refer  to  the 
attachment. 

The  compiler  is  allowed  to  read  from  all  sublibraries  constituting  the 
current  program  library,  but  only  the  current  sublibrary  may  be  changed. 

2.4.1  Correct  Compilations 

In  this  section,  it  is  assumed  that  the  compilation  units  are  correctly  com¬ 
piled,  i.e.  that  no  errors  are  detected  by  the  compiler. 
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Compilation  of  a  LibraTy  Unit  Which  Is  a  Declaration 

If  a  declaration  unit  of  the  same  name  as  the  one  currently  being  com¬ 
piled  exists  in  the  current  sublibrary,  it  is  deleted  together  with  its 
body  unit  and  the  body’s  possible  subunits.  A  new  declaration  unit  is 
inserted  in  the  sublibrary. 

Compilation  of  a  Library  Unit  Which  Is  a  Subprogram  Body 

A  subprogram  body  in  a  compilation  unit  is  treated  as  a  secondary 
unit  if  the  current  sublibrary  contains: 

•  a  valid  subprogram  declaration  of  the  same  name,  or 

•  a  valid  generic  subprogram  declaration  of  the  same  name. 

In  all  other  cases,  it  will  be  treated  as  a  library  unit,  i.e.: 

•  when  there  is  no  library  unit  of  that  name, 

•  when  there  is  an  invalid  declaration  unit  of  that  name, 

•  when  there  is  a  package  declaration,  generic  package  declaration 
or  an  instantiated  package  or  subprogram  of  that  name. 

Compilation  of  a  Library  Unit  Which  Is  an  Instantiation 

A  declaration  unit  with  the  name  of  the  compilation  unit  in  the  cur¬ 
rent  sublibrary  is  deleted  (if  it  exits)  with  its  body  unit  and  possible 
subunits.  A  new  declaration  unit  is  inserted. 

Compilation  of  a  Secondary  Unit  Which  Is  a  Library  Unit  Body 

The  existing  body  is  deleted  from  the  sublibrary  together  with  its  pos¬ 
sible  subunits.  A  new  body  unit  is  inserted. 

Compilation  of  a  Secondary  Unit  Which  Is  a  Subunit 

If  the  subunit  exists  in  the  sublibrary,  it  is  deleted  with  its  possible 
subunits.  A  new  subunit  is  inserted. 
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2.4.2  Incorrect  Compilations 

If  the  compiler  detects  an  error  in  a  compilation,  the  program  library  will 
remain  unchanged. 

Note  that  if  a  file  consists  of  several  compilation  units  and  an  error  is 
detected  in  any  of  these  compilation  units,  the  program  library  will  not  be 
updated  for  any  of  the  compilation  units. 


LINKER  OPTIONS 


The  linker  options  of  this  Ada  Implementation,  as  described  In  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  documentation  and 
not  to  this  report. 


3  COMMANDS  OF  THE  ADA  LINKER 


27 


3  Commands  of  The  Ada  Linker 

Before  a  compiled  Ada  program  can  be  executed,  it  must  be  linked  by  the 
Ada  Linker. 

The  Ada  Linker  performs  two  different  jobs: 

•  It  links  an  Ada  program.  The  linker  will  check  the  consistency  of  the 
program  (cf.  section  2.3)  and  decide  an  elaboration  order  for  the  units 
constituting  the  program.  Any  errors  found  will  be  reported  on  the 
standard  output  and  optionally  on  a  log  file.  If  no  errors  are  found,  an 
executable  image  file  will  be  produced. 

•  It  examines  the  consecjuences  of  recompilations.  The  linker  will  check 
the  consistency  of  the  specified  program  units  (cf.  section  2.3)  as  if  the 
specified  recompilations  were  actually  performed,  and  determine  an 
elaboration  order  for  the  program.  Any  errors  found  vdll  be  reported 
on  the  standard  output  and  optionally  on  a  log  file,  together  with  a  list 
of  needed  recompilations. 

It  is  possible  to  check  the  consequences  of  no  recompilations,  in  which  case 
the  linker  will  check  the  consistency  of  the  specified  program  units  as  they 
appear  in  the  current  program  library. 


3.1  The  Invocation  Command 

The  linker  is  invoked  by  submitting  the  following  command  to  the  command 
language  interpreter: 


alv70  {<options>}  <unit-iicune > 


<unit_name> 

If  a  linking  is  requested,  <unit_name>  must  specify  a  main  program 
which  is  a  library  unit  of  the  current  program  library,  but  not  neces¬ 
sarily  of  current  sublibrary.  The  library  unit  must  be  a  parameterless 
procedure.  Wildcard  characters  are  not  permitted. 
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If  examination  of  the  consequences  of  recompilations  is  requested,  <vmit 
specifies  a  set  of  program  library  units  whose  consistency  after  the  hy¬ 
pothetical  recompilations  will  be  checked.  <unit_name>  may  contain 
wildcard  characters  which  will  be  interpreted  according  to  the  rules  of 
the  UNIX  in  the  current  sublibrary  with  names  that  match  specified 
<unit_name>.  All  types  of  library  unit  may  be  designated. 

1.  Options 

—  1  <f  ile_nauiie> 

Causes  the  linker  to  produce  a  log  file  named  <f  ile_naine>.  The 
log  file  is  written  to  the  invoker’s  current  directory. 

-L 

Causes  the  linker  to  produce  a  log  file  named  ’’link.log”.  The 
log  file  is  written  to  the  invoker’s  current  directory. 

—  a  <lib_spec> 

Specifies  the  current  sublibrary  and  thereby  also  the  current  pro¬ 
gram  library.  If  this  option  is  omitted  then  is  sublibrarv  des¬ 
ignated  by  the  environment  variable  ADA_LIBRARY  is  used.  If  the 
environmental  variable  is  not  denied,  the  file  ADA.LIBRARY  is  used. 

—  c 

causes  the  linker  to  check  the  the  consistency  of  the  program(s) 
specified  by  <unit_naine>.  If  this  option  is  omitted  then  the 
specified  program  will  be  linked. 

—  s  <unit_set>  and  — b  <unit_set> 

Define  those  library  units  after  whose  hypothetical  recompilations 
the  consistency  will  be  checked.  The  meaning  of  <unit_set>  is; 
<unit_set>  ::=  <unit_nciine>  {,  <  unit  .name'-} 

For  those  unit  names  that  appear  with  the  — s  option,  the  specifi¬ 
cations  of  the  corresponding  library  units  are  included  in  the  list 
of  hypothetical  recompilations. 

For  those  unit  names  that  appear  with  the  — b  o])tion.  the  bod¬ 
ies  of  the  corresponding  library  units  are  included  in  the  list  of 
hypothetical  recompilations. 

A  <unit_name>  may  appear  in  the  <unit-set>  of  both  options 
if  required. 
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— T  <test_code> 

Causes  the  linker  to  send  test  output  to  the  log  file.  The  <rtest_code> 
is  an  integer  in  the  range  0..9.  This  option  is  only  allowed  if  the 
—  1  or  — L  option  is  present. 

—  o  <filename> 

Include  the  file  denoted  by  <filename>  in  the  link.  Useful  for 
including  entities  written  in  assembly  language  or  C. 

— p  "string" 

Options.  The  string  will  be  inserted  immediately  after  the  ”ld” 
command  when  the  native  linker  is  invoked.  Useful  for  supplying 
options  for  the  linker. 

— D  <stack> 

Default  stack— size,  specifies  the  amount  of  stack  allocated  for 
task  of  a  task  type  for  which  a  length  clause  is  not  specified. 

2.  Examples 

$  alv70  -a  mylib  myprog 

The  linker  will  generate  an  executable  image  in  the  current  directory 
from  the  program  from  the  library  mylib. 

$  alv70  -L  -c  -s  example  -b  utility  myprog 

This  will  examine  the  consequences  of  the  recompilations  of  the  ex¬ 
ample  specification  and  the  utility  body.  The  linker  will  give  a  list  of 
necessary  compilations  to  keep  myprog  consistent.  The  program  library 
is  given  by  the  environment  variable  ADA_LIBRARY. 

$  alv70  -c  -s  a+b  -b  c  prog.x 

Here  the  linker  will  examine  the  consistency  of  the  program  ”prog_x” 
in  case  of  a  recompilations  of  the  specifications  of  the  library  unit  ”a” 
and  all  library  units  with  names  starting  with  ”b”,  and  a  recompilation 
of  the  bodies  of  the  all  library  units  with  names  starting  ”c”. 

$  alv70  -o  ObjectFile.o  myprogram 
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The  linker  will  include  the  code  in  ObjectFile.o  in  the  linkage  ot  the 
program  ’’myprogram”.  This  program  presumably  features  a  program 
interface  to  some  routines  appearing  in  the  ObjectFile. 


4  Options  for  The  Ada  System  generator 

asgv70  is  a  system  that  generates  a  load  module  of  RX-UX832  from  a  SG 
definition  file,  object  module  files  generated  by  alv70. 

4.1  The  Invocation  Command 

The  Invocation  command  has  the  following  syntax. 


asgv70  {<option>}  <SG— definition— file— name> 

1.  Options 

The  following  options  are  permitted: 

—  a  <library— spec> 

Specifies  default  Ada  libraries. This  option  is  used  for  a  program 
for  which  adaJib  is  not  specified  in  SG  definition  file.  This  optiojn 
specifies  the  value  of  adaJib  in  SG  definition. 

—  conv 

Convert  endians  of  the  load  module  form  big(host  cpu)  to  lit- 
tle( target  cpu). 

— h  and  — H 

Displays  messages  for  options. 

—  int  <interrupt_mask>  [,  <interrupt_inask>  ...] 

Specifies  interrupt_masks  permitted  by  the  task  that  is  activated 
first.  Notation  of  a  interrupt_mask  is  a  numeric  literal  notation  of 
Ada  (eg.  16#fF0#). 

—  i  <file_name> 

This  option  is  used  for  a  program  for  which  obj .module  is  NOT 
specified  in  SG  definition  file.  This  option  specifies  the  value  of 
objjTiodule  in  SG  definition  file. 
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— m  <progreLm_naune> 

This  option  is  used  for  a  program  for  which  main_piogram  is  NOT 
specified  in  SG  definition  file.  This  option  specifies  the  value  of 
main-program  in  SG  definition  file. 

—  o  <file_name> 

Specifies  the  name  of  load  module  generated  by  asgv70.  If  the 
name  is  omitted,  the  load  module  name  is  vsld.out. 

-P 

Specifies  that  temporary  files  generated  by  asgv70  are  not  re¬ 
moved,  but  are  moved  to  the  directory  specified  by  -ts  option. 

— R  [<file_name>] 

Specifies  that  application  load  modules  and  the  kernel  load  module 
are  generated  in  different  files.  Specified  file  name  is  a  kernel  load 
module  name.  If  a  file_name  is  omitted,  a  kernel  load  module 
name  is  kernlm. 

-RA 

Specifies  that  only  application  load  modules  are  generated. 

— RK  [<f ile_naine>] 

Specifies  that  only  a  kernel  load  module  are  generated.  Specified 
file  name  is  a  kernel  load  module  name.  If  a  file_name  is  omitted, 
the  kernel  load  module  name  is  kernlm. 

—  t  <directory_neun9> 

Specifies  a  directory  for  temporary  files  generated  by  asgv70  and 
vsld  commands.  If  a  directory  .name  is  omitted,  temporary  files 
for  asgv70  are  generated  in  the  current  directory,  and  temporary 
files  for  vsld  are  generated  in  /tmp  directory. 

—  tl  [<f ile_ncune>] 

Specifies  the  name  of  a  task  library  file  generated  by  vsld  com¬ 
mand.  If  the  file_name  is  not  specified,  the  task  library  file  name 
is  a  name  of  SG  definition  file  following  ”.1”.  Without  this  option, 
a  task  library  file  generated  by  vsld  command  is  removed. 

—  ts  <directory-najie> 

Specifies  the  name  of  a  directory  for  temporary  files  generated  by 
asgv70. 
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—tv  <directory_iiaLme> 

Specifies  the  name  of  a  directory  for  temporary  files  generated  by 
vsld  commands  of  RX-UX832  that  is  called  in  asgvTO. 

— V 

Displays  the  RX-UX832  commands  called  by  asgvTO. 

-V 

Displays  the  version  of  asgvTO.  No  load  module  is  generated 


APPENDIX  C 
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The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent 
conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The 
implementation-dependent  characteristics  of  this  Ada  implementation, 
as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to 
compiler  documentation  and  not  to  this  report. 
Implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are: 

package  STANDARD  is 

type  SHORT_INTEGER  is  range  -32_768. . 32_767 ; 

type  INTEGER  is  range  -2_147_483_648. .2_147_483_647 ; 

type  FLOAT  is  digits  6 

range  -16#0.FFFF_FF#E32. .16#0.FFFF_FF#E32; 

type  LONG_FLOAT  is  digits  15 

range  -16#0.FFFF_FFFF_FFFF_F8#E256. . 16#0 . FFFF_FFFF_FFFF_F8#E256 ; 
type  DURATION  is  delta  2#1.0#E-14  range  -131_072 . 0. . 131_071. 0; 

end  STANDARD; 
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1  Introduction 

This  appendix  describes  the  implementation-dependent  characteristics  of  the 
NEC  Ada  Compilation  System  for  EWS-UX/V  to  V70/RX-UX832  as  re¬ 
quired  in  the  Appendix  F  frame  of  the  Ada  Reference  Manual(  ARM,  ANSI/MIL- 
STD  1815A). 

2  Implementation-Dependent  Pragmas 

This  section  lists  the  language  defined  pragmas,  any  restrictions  on  their 
use,  and  their  effect  compared  to  ARM  explanation.  This  section  also  lists 
implementation — dependent  pragmas. 

2.1  Language  Defined  Pragmas 

CONTROLLED 

This  pragma  has  no  effect.  No  automatic  reclaiming  of  storage  is  per¬ 
formed. 

ELABORATE 

As  in  ARM. 

INLINE 

Pragma  INLINE  causes  inline  expansion  except  in  the  following  cases: 

1.  The  whole  body  of  the  subprogram  for  which  inline  expansion  is 
wanted  has  not  been  seen.  This  ensures  that  recursive  procedures 
cannot  be  inline  expanded. 

2.  The  subprogram  call  appears  in  an  expression  on  which  confor¬ 
mance  check  may  be  applied,  i.e.  in  a  subprogram  specification, 
in  a  discriminant  part,  or  in  a  formal  part  of  an  entry  declaration 
or  accept  statement. 

See  the  following  example: 

1  Package  inline.test  is 

2 

3  function  one  return  integer; 
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4  pragma  inline  (one); 

5 

6  end  inline _test; 

7 

8  package  body  inline.test  is 

9 

10  function  one  return  integer  is 

11  begin 

12  return  1 ; 

13  end  one; 

14 

15  procedure  def_parms  (parm  :  integer  :=  one)  is 

***  46W-0:  Warning  :  Inline  expcoision  of  ONE  is  not  achieved 
here 

16  begin 

17  null; 

18  end  def.parms; 

19 

20  end  inline.test; 

21 

3.  The  subprogram  is  an  instantiation  of  the  predefined  generic  sub¬ 
programs  UNCHECKED.CONVERSION  or  UNCHECKED-DEALLOCATION. 

4.  The  subprogram  is  declared  in  a  generic  unit.  The  body  of  that 
generic  unit  is  compiled  as  a  secondary  unit  in  the  same  compila¬ 
tion  as  a  unit  containing  a  call  to  (an  instance  of)  the  subprogram. 

See  the  following  example: 

1  —  A  compilation  with  there  units: 

2  generic 

3  package  g  is 

4  procedure  P; 

5  pragma  inline (  p  ); 

6  end  g; 

7 

8  package  body  g  is 

9  procedure  p  is 
10  begin 
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11  null; 

12  end  p; 

13  end  g; 

14 

15  with  g; 

16  procedure  example  is 

17  package  n  is  new  g; 

18  begin 

19  n.p; 

43W-0:  Warning  Inline  expansion  of  P  is  not  achieved  here 

20  end  excimple: 

5.  The  subprogram  is  declared  by  a  renaming  declaration. 

6.  The  subprogram  is  passed  as  a  generic  actual  parameter. 

A  warning  is  given  if  inline  expansion  is  not  achieved. 

INTERFACE 

Pragma  INTERFACE!  is  supported  with  C  and  V70  assembly  language 
(AS)  as  target  languages. 

The  following  restrictions  exist: 

•  The  name  of  an  interfaced  subprogram  must  not  have  more  that 
30  characters.  If  name  is  over  30  characters,  it  is  truncated. 

•  Case  is  significant  in  C,  but  not  ion  Ada.  This  conflict  is  resolved 
by  matching  the  Ada  name  of  an  interfaced  subprogram  with  a 
lower-case  version  of  the  name  in  C  and  prefix  with  a 

•  User-declared  name  starting  with  the  string  ’’.ada”. 

The  following  rules  exist  for  the  matching  of  Ada  types  with  C  types: 

•  the  following  non-composite  Ada  type  map  directly  onto  an  equiv¬ 
alent  C  type. 
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Ada 

C 

SHORTJNTEGER 

short 

INTEGER 

int,  long 

enumeration 

int 

CHARACTER 

int 

BOOLEAN 

int 

FLOAT 

float 

LONG.FLOAT 

double 

When  occurring  as  parameters  of  mode  IN,  objects  of  these  type 
are  assumed  passed  by  value;  when  used  as  parameters  of  mode 
IN  OUTor  OUT  they  are  assumed  to  be  passed  by  address.  Ada 
functions  returning  such  types  do  so  by  value. 

•  Objects  of  record  types  are  passed  by  address,  regardless  of  size, 
for  all  parameter  modes  and  for  function  return  values.  Only 
constrained  record  types  can  be  interfaced. 

•  For  objects  of  array  types,  the  address  of  a  data  area  alone  is 
passed,  regardless  of  dimensions,  bounds  or  mode.  Unconstrained 
array  types  may  not  be  used  as  parameters  of  mode  IN  OUT  or 
OUT,  or  as  function  return  values. 

•  Ada  unpacked  arrays  of  type  CHARACTER  interface  with  C  type 
(int  *)  .  Ada  objects  of  type  STRING  interface  with  C  type  (char 
*).  It  should  be  remembered  that  type  STRING  is  packed  (see 
ARM,  Appendix  C/17). 

•  Fixed  types  have  no  natural  counterpart  in  C  and  cannot  be  in¬ 
terfaced. 

LIST 

As  in  ARM. 

MEMORY.SIZE 

Not  supported,  cf.  Pragma  SYSTEM-NAME. 

OPTIMIZE 

This  pragma  has  no  effect. 

PACK 

This  pragma  has  the  following  form: 
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Pragma  PACK  (type_simple_name) 

It  is  legal  to  specify  this  pragma  for  array  and  record  types.  It  has 
no  effect  on  record  objects.  The  array  components  must  be  of  a  dis¬ 
crete  type,  i.e.  integer,  short Jnteger,  and  enumeration  types  (including 
boolean  and  character). 

The  pragma  has  the  effect  that  object  of  the  given  type  are  packed 
into  the  nearest  2**n  bits  large  enough  to  accomodate  the  object.  For 
example,  an  object  with  a  size  of  3  bits  is  packed  into  4  bits. 

PAGE 

As  in  ARM. 

PRIORITY 

As  in  ARM. 

SHARED 

Not  allowed  for  variables  of  type  L0NG-FL0.4T  or  subtypes  or  derived 
types  thereof. 

STORAGE.UNIT 
Has  no  effect. 

SUPPRESS 

The  implementation  only  supports  the  following  form  of  the  pragma: 
Pragma  SUPPRESS  (identifier); 

where  identifier  is  one  of  the  identifiers  defined  in  ARM,  Section  8.7, 
i.e.  it  is  not  possible  to  restrict  the  omission  of  a  certain  check  to  a 
specified  name. 

SYSTEM^AME 

Not  supported.  The  only  meaningful  SYSTEMJIAME  is  EWS-UVX_R4  when 
using  the  EWS_UXV_R4  version  of  the  Ada  Compiler. 
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2.2  Implementation  Defined  Pragmas 

INTERFA  CE.SP  ELLIN  G 

This  pragma  allows  the  user  to  call  interfaced  subprograms  that  have 
names  that  cannot  be  given  to  Ada  subprograms  because  of  Ada’s  lex¬ 
ical  rules.  Pragma  interfacejspelling  supplies  a  mapping  between  the 
name  of  an  Ada  subprogram  (that  is  mentioned  in  a  pragma  interface) 
and  the  name  under  which  the  subprogram  is  known  in  the  surround¬ 
ings. 

Example 


function  Allocate  (seize:  integer)  return  byte.ptr;  pragma  interface 
—  Supply  the  name  of  the  c  allocate  function 
pragma  interf ace.spelling  (Alloc,  "alloc"); 

If  no  pragma  interface-spelling  is  given  for  an  interfaced  subprogram, 
the  result  will  be  as  if  a  pragma  interface-spelling  had  been  given  with 
a  string  containing  the  Ada  spelling  of  the  subprogram  in  lower  case: 

pragma  interface  (C,  Some _funct ion ) ; 

—  Implicit  pragma  interf ace.spelling 
(  some_f unction ,  "some_function") ; 

pragma  interface  (AS,  Some_f unction) 

—  Implicit  pragma  interf ace_spelling 
(some.f unction,  "SOHE.FUNCTION") 

ABSTRA  CT.A  CODEJNSERTIONS 

This  pragma  enables  rode  statements  in  abstract  acode. 

CONCURRNCY 

This  pragma  can  appeare  in  the  declarative  part  of  a  task  and  a  library 
subprogram.  It  has  one  integer  argument  which  limits  concurrency 
of  the  task  type  in  the  system  (not  in  a  program).  A  concurrency  is 
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associated  with  the  main  program  if  this  pragma  appears  in  its  outer 
most  declarative  part.  This  pragma  has  no  effect  if  it  occures  in  a 
subprogram  other  than  the  main  program. 

INTERRUPTMASK 

This  pragma  can  appear  in  the  declarative  part  of  a  task  and  a  library 
subprogram.  It  has  no  arguments.  If  it  appears,  no  interrupts  are  ac¬ 
cepted  while  the  task  is  executing.  A  interrupt  mask  is  associated  with 
the  main  program  if  this  pragma  appears  in  its  outer  most  declarative 
part.  This  pragma  has  no  effect  if  it  occures  in  a  subprogram  other 
than  the  main  program. 

TIME.SLICE 

This  pragma  can  appear  in  the  declarative  part  of  a  task  and  a  library 
subprogram.  It  has  one  integer  argument  which  specifies  time  slice 
value  of  the  task  type  in  miliseconds.  A  time  slice  is  associated  with 
the  main  program  if  this  pragma  appears  in  its  outer  most  declarative 
part.  This  pragma  has  no  effect  if  it  occures  in  a  subprogram  other 
than  the  main  program. 

DATA.PRESERVE 

This  pragma  has  no  argument.  If  it  appears  in  the  outer  most  declar¬ 
ative  part  of  main  program,  a  level  C  restart  of  the  operating  system 
does  not  initialize  statically  allocated  data.  This  pragma  has  no  effect 
if  it  occures  in  a  subprogram  other  than  the  main  program. 

PHYSICAL.ADDRESS 

This  pragma  has  one  arguemnt,  variable  name  which  is  also  a  specified 
address  clause  in  the  same  declarative  part.  If  this  pragma  is  specified, 
the  address  of  the  address  clause  denotes  a  physical  address  rather 
than  a  virtual  address.  In  this  case  physical  memory  is  mapped  to 
virtual  space  and  the  variable  is  accessed  via  the  mapping.  Because  an 
address  attribute  of  a  variable  denotes  a  virtual  address  of  the  variable, 
the  attribute  does  not  confirm  the  address  of  the  address  clause. 


ROM 

This  pragma  has  one  arguemnt,  a  variable  name,  which  is  also  a  spec¬ 
ified  address  clause  in  the  same  declarative  part.  This  jjragma  implies 
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a  pragma  physicaLacldress.  If  this  pragma  is  specified,  its  physical 
memory  is  treated  as  a  ROM  device. 


RAM 

This  pragma  has  one  arguemnt,  a  variable  name,  which  is  also  a  spec¬ 
ified  address  clause  in  the  same  declarative  part.  This  pragma  implies 
a  pragma  physicaLaddress.  If  this  pragma  is  specified,  its  physical 
memory  is  treated  as  a  RAM  device  and  0  cleared  at  the  boot  time. 

10. SPACE 

This  pragma  has  one  arguemnt,  a  variable  name,  which  is  also  a  spec¬ 
ified  address  clause  in  the  same  declarative  part.  This  pragma  implies 
a  pragma  physicaLaddress.  If  this  pragma  is  specified,  its  physical  ad¬ 
dress  is  treated  as  an  I/O  address.  The  variable  is  mapped  to  the  I/O 
space  of  V70  rather  than  memory  space. 

INTERFACEJ.OCAL 

This  pramga  has  one  argument,  a  subprogram  name  which  is  also  spec¬ 
ified  in  pragma  interface.  If  this  pragma  is  specified,  the  object  file  of 
external  subprogram  is  assumed  to  be  linked  to  each  task.  Statically 
allocated  data  in  the  object  file  has  different  addresses  for  each  tasks. 


3  Implementation-dependent  Attributes 

No  implementation-dependent  attributes  are  defined. 

4  Package  SYSTEM 


package  SYSTEM  is 

type  ADDRESS 
subtype  PRIORITY 
type  NAME 
SYSTEM.NAME: 
STORAGE.UNIT: 


is  new  INTEGER; 
is  INTEGER  range  0  ..  255; 
is  (  V70_RXUX  ); 
constant  NAME  :=  V70_RXUX; 
constant  :=  8; 
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MEMORY.SIZE: 

constant 

= 

2048  *  1024; 

MIN.INT: 

const  amt 

= 

-2.147.483.648; 

MAX.INT: 

constant 

= 

2.147.483.647; 

MAX.DIGITS : 

constant 

= 

15; 

MAX.MANTISSA: 

constant 

= 

31; 

FINE.DELTA : 

constant 

= 

2#1.0#E-31; 

TICK: 

constant 

= 

0.001; 

type  interface. language 

is  (C.AS); 

—  Compiler  system  dependent  types: 


subtype  INTEGER. 16  is 
subtype  NATURAL. 16  is 
subtype  POSITIVE. 16  is 


SHORT. INTEGER; 

INTEGER. 1 6  range  0 . . INTEGER. 1 6 ’ LAST ; 
INTEGER.16  range  1 .. INTEGER. 16 'LAST; 


subtype  INTEGER.32  is  INTEGER; 

subtype  NATURAL.32  is  INTEGER.32  range  0 .. INTEGER.32 ’ LAST; 
subtype  P0SITIVE.32  is  INTEGER.32  range  1 .. INTEGER.32 'LAST; 


5  Representation  Clauses 

The  representation  clauses  that  are  accepted  are  described  below.  Note  that 
representation  specification  can  be  given  on  derived  types  too. 


5.1  Pragma  PACK 

Pragma  PACK  applied  on  an  array  type  will  pack  each  array  element  into 
the  smallest  number  of  bits  possible,  assuming  that  the  component  type  is  a 
discrete  type  other  than  LONG_INTEGER  or  a  fixed  point  type.  Packing  of 
arrays  having  other  kinds  of  component  types  have  no  effect. 

When  the  smallest  number  of  bits  needed  to  hold  any  value  of  a  type  is 
calculated,  the  range  of  the  types  is  extended  to  include  zero. 
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Pragma  PACK  applied  on  a  record  type  will  attempt  to  pack  the  com¬ 
ponents  not  already  covered  by  a  representation  clause( perhaps  none).  This 
packing  will  begin  with  the  small  scalar  components  and  larger  components 
will  follow  in  the  order  specified  in  the  record.  The  packing  begins  at  the 
first  storage  unit  after  the  components  with  representation  clauses. 

The  component  types  in  question  are  the  ones  defined  above  for  array 
types. 


5.2  Length  Clauses 

Four  kinds  of  length  clauses  are  accepted. 

1.  Size  specifications: 

The  size  attribute  for  a  type  T  is  accepted  in  the  following  cases: 

(a)  If  T  is  a  discrete  type,  then  the  specified  size  must  be  greater  than 
or  equal  to  the  number  of  bits  needed  to  represent  a  value  of  the 
type,  and  less  than  or  equal  to  32.  Note  that  when  the  number  of 
bits  needed  to  hold  any  value  of  the  type  is  calculated,  the  range 
is  extended  to  include  0  if  necessary,  i.e.  the  range  3. .4  cannot  be 
represented  in  1  bit,  but  needs  3  bits. 

(b)  If  T  is  a  fixed  point  type,  then  the  specified  size  must  be  greater 
than  or  equal  to  the  smallest  number  of  bits  needed  to  hold  any 
value  of  the  fixed  point  type,  and  less  than  32  bits.  Note  that  the 
Ada  Reference  Manual  permits  a  representation,  where  the  lower 
bound  and  the  upper  bound  is  not  representable  in  the  type.  Thus 
the  type 

type  FIX  is  delta  1.0  range  -1.0  ..  7.0; 

is  representable  in  3  bits.  As  for  discrete  types,  the  number  of  bits 
needed  for  a  fixed  point  type  is  calculated  using  the  range  of  the 
fixed  point  type  possibly  extended  to  include  0.0. 

(c)  If  T  is  a  floating  point  type,  an  access  type  or  task  type  the  spec¬ 
ified  size  must  be  equal  to  the  number  of  bits  used  to  represent 
values  of  the  type  (floating  points:  32  or  64,  access  types  :  32  bits 
and  task  types:  32  bits). 
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(d)  K  T  is  a  record  type,  the  specified  size  must  be  greater  than  or 
equal  to  the  minimal  number  of  bits  used  to  represent  values  of 
the  type  per  default. 

(e)  If  T  is  an  array  type,  the  size  of  the  array  must  be  static,  i.e. 
known  at  compile  time  and  the  specified  size  must  be  equal  to  the 
minimal  number  of  bits  used  to  represent  values  of  tiie  r ype  per 
default. 

Furthermore,  the  size  attribute  has  effect  only  if  the  type  is  part  of  a 
composite  type. 

type  BYTE  is  range  0..255; 
for  BYTE ’size  use  8; 

SIXTEEN  :  BYTE;  —  one  word  allocated 

EIGHT  ;  array(1..4)  of  BYTE;  —  one  byte  per  element 

2.  Collection  size  specifications: 


Using  the  STORAGE-SIZE  attribute  on  an  access  type  will  set  an  up¬ 
per  limit  on  the  total  size  of  objects  allocated  in  the  collection  allocated 
for  the  access  type.  If  further  allocation  is  attempted,  the  exception 
STORAGE-ERROR  is  raised.  The  specified  storage  size  must  be  less 
than  or  equal  to  INTEGER’LAST. 

3.  Task  storage  size: 


When  the  STORAGE-SIZE  attribute  is  given  on  a  task  type,  the  task 
stack  area  will  be  of  the  specified  size.  There  is  no  upper  limit  on  the 
given  size. 

4.  Small  specifications: 


Any  value  of  the  SMALL  attribute  less  than  the  specified  delta  for  the 
fixed  point  type  can  be  given. 
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5.3  Enumeration  Representation  Clauses 

Enumeration  representation  clauses  may  specify  representations  in  the  range 
of  INTEGER’FIRST+1..INTEGER’LAST-1.  An  enumeration  representa¬ 
tion  clause  may  be  combined  with  a  length  clause.  If  an  enumeration  rep¬ 
resentation  clause  has  been  given  for  a  type,  the  representational  values  are 
considered  when  the  number  of  the  bits  needed  to  hold  any  value  of  the  type 
is  evaluated.  Thus  the  type 

type  ENUM  is  (A,  B,  C); 

for  ENUM  use  (1,  3,  5); 

needs  3  bits  not  2  bits  to  represent  any  value  of  the  type  ENUM. 

5.4  Record  Representation  Clauses 

When  component  clauses  are  applied  to  a  record  type  the  following  restric¬ 
tions  and  interpretations  are  imposed: 

•  All  values  of  the  component  type  must  be  representable  within  the 
specified  number  of  bits  in  the  component  clause. 

•  If  the  component  type  is  either  a  discrete  type,  a  fixed  point  type,  an 
array  type  with  a  discrete  type  or  a  fixed  point  type  as  element  type, 
then  the  component  is  packed  into  the  specified  number  of  bits  (see 
however  the  restriction  in  the  paragraph  above),  and  the  component 
may  start  at  any  bit  boundary. 

•  If  the  component  type  is  not  one  of  the  types  specified  in  the  paragraph 
above,  it  must  start  at  a  storage  unit  boundary,  a  storage  unit  being  8 
bits,  and  the  default  size  calculated  by  the  compiler  must  be  given  as 
the  bit  width,  i.e.  the  component  must  be  specified  as 

component  at  N  range  0.,16*M-1 

where  N  specifies  the  relative  storage  unit  number  (0,  1,  ....)  from  the 
beginning  of  the  record,  and  M  the  required  number  of  storage  units  ( 1, 
2,  ...). 

•  The  maximum  bit  width  for  components  of  scalar  types  is  32. 
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•  A  record  occupies  an  integral  number  of  storage  units. 

•  A  record  may  take  up  a  maximum  of  32Kbits. 

•  If  the  component  type  is  an  array  type  with  discrete  type  or  a  fixed 
point  type  as  element  type,  the  given  bit  width  must  be  divisible  by 
the  length  of  the  array,  i.e.  each  array  element  will  occupy  the  same 
number  of  bits. 

If  the  record  type  contains  components  which  are  not  covered  by  a  com¬ 
ponent  clause,  they  are  allocated  consecutively  after  the  component  with 
the  value.  Allocation  of  a  record  component  without  a  component  clause  is 
always  aligned  on  a  storage  unit  boundary.  Holes  created  because  of  compo¬ 
nent  clauses  are  not  otherwise  utilized  by  the  compiler. 

1.  Alignment  Clause 

Alignment  clause  for  records  are  implemented  with  the  following  char- 
acteristics; 

•  If  the  declaration  of  the  record  type  is  done  at  the  outermost  level 
in  a  library,  any  alignment  is  accepted. 

•  If  the  record  declaration  is  done  at  a  given  static  level  (higher 
than  the  outermost  library  level,  i.e.  the  permanent),  only  word 
alignments  are  accepted. 


6  Implementation-Dependent  Names 

None  defined  by  the  compiler. 

7  Address  Clauses 


This  section  describes  the  implementation  of  address  clause  and  what  types 
of  entities  may  have  their  address  specified  by  the  user. 
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7.1  Objects 

Address  clauses  are  supported  for  scalar  and  composite  objects  whose  size 
can  be  determined  at  compile  time.  The  address  value  must  be  static.  The 
given  address  is  the  virtual  address. 


8  Unchecked  Conversion 

Unchecked  conversion  is  only  allowed  for  types  where  objects  of  the  same 
’’size”.  The  size  of  an  object  is  interpreted  as  follows  : 

•  for  arrays,  it  is  the  number  of  storage  units  occupied  be  the  array 
elements. 

•  for  records  it  is  the  size  of  the  fixed  part  of  the  record,  i.e.  excluding 
any  dynamic  storage  allocated  outside  the  record. 

•  for  the  other  non-structured  type,  the  object  size  is  as  described  in 
Chapter  9. 

For  scalar  types  having  a  size  specification,  special  rules  apply.  Conver¬ 
sion  involving  such  a  type  is  allowed  if  the  given  size  matched  either  the 
specified  size  or  the  object  size. 

Example 


type  ACC  is  access  INTEGER; 

function  TO.INT  is  new  UNCHECKED_CONVERSION(ACC ,  INTEGER): 

--  OK 

function  T0_ACC  is  new 

UNCHECKED_CONVERSION(SHORT_INTEGER,  ACC,  I); 

--  NOT  OK 

type  UNSIGNED  is  range  0.. 65535; 
for  UNISGNED’SIZE  use  16; 

function  TO.INT  is  new  UNCHECKED.CONVERSION (UNSIGNED ,  INTEGER): 

--  OK 
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function  TO.SHORT  is  new 

UNCHECKED_CONVERSION(UNSIGNED.  SHORT. INTEGER) ; 

--  OK 

End  of  example 


9  Input- Output  Packages 

The  implementation  supports  all  requirements  of  the  Ada  language  and  the 
POSIX  standard  described  in  document  Pi 003.5  Draft4.0/WG15-N45.  It  is 
an  effective  interface  to  the  UNIX  file  system,  and  in  the  case  of  text  I/O  it 
is  also  an  effective  interface  to  the  UNIX  standard  input,  standard  output 
and  standard  error  streams. 

This  section  describes  the  functional  aspects  of  the  interface  to  the  UNIX 
file  system,  including  the  methods  of  using  the  interface  to  take  advantage 
of  the  file  facilities  provided. 

The  Ada  input-output  concept  as  defined  in  Chapter  14  of  the  ARM 
does  not  constitute  a  complete  functional  specification  of  the  input-output 
packages.  Some  aspects  of  I/O  system  are  not  discussed  at  all,  while  others 
are  intentionally  left  open  for  implementation.  This  section  describes  those 
sections  not  covered  in  the  ARM.  Please  notice  that  the  POSIX  standard 
puts  restrictions  on  some  of  the  aspects  not  described  in  Chapter  14  of  the 
ARM. 

The  UNIX  operating  system  considers  all  files  to  be  sequences  of  char¬ 
acters.  Files  can  either  be  accessed  sequentially  or  randomly.  Files  are  not 
structured  into  records,  but  an  access  routine  can  treat  a  file  as  a  sequence 
of  records  if  it  arranges  the  record  level  input-output. 

Note  that  for  sequential  or  text  files  (Ada  files  not  UNIX  external  files) 
RESET  on  a  file  in  mode  OUTJ'ILE  will  empty  the  file.  Also,  a  sequential 
oi  text  file  opened  as  an  OUTJFILE  will  be  emptied. 

9.1  External  Files 

An  external  file  is  either  a  UNIX  disk  file,  a  UNIX  FIFO  (named  pipe),  a 
UNIX  pipe,  or  any  device  defined  in  the  UNIX  directory.  The  use  of  devices 
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such  as  a  tape  or  communication  line  may  require  special  access  permissions 
or  have  restrictions.  If  an  inappropriate  operation  is  attempted  on  a  device, 
then  USE-ERROR  exception  is  raised. 

External  files  created  within  the  UNIX  file  system  shall  exist  after  the 
termination  of  the  program  that  created  it,  and  will  be  accessible  from  other 
Ada  programs.  However,  pipes  and  temporary  files  will  not  exist  after  pro¬ 
gram  termination. 

Creation  of  a  file  with  the  same  name  as  an  existing  external  file  will 
cause  the  existing  file  to  be  overwritten. 

Creation  of  files  with  mode  IN_FILE  will  cause  USE-ERROR  to  be  raised. 
The  name  parameter  to  the  input-output  routines  must  be  a  valid  UNIX 
file  name.  If  the  name  parameter  is  empty,  then  a  temporary  file  is  created 
in  the  /usr/tmp  directory.  Temporary  files  are  automatically  deleted  when 
they  are  closed. 

9.2  File  Management 

This  section  provides  useful  information  for  performing  file  management  func¬ 
tions  within  an  Ada  program. 

1.  Restrictions  on  Sequential  and  Direct  Input- Output 

The  only  restrictions  are  that  placed  on  the  element  size,  i.e.  the  num¬ 
ber  of  bytes  occupied  by  the  ELEMENT-TYPE  :  the  maximum  size 
allowed  is  2147483647  bits;  and  if  the  size  of  the  type  is  variable  ,  the 
maximum  size  must  be  determinable  at  the  point  of  instantiation  from 
the  value  of  the  SIZE  attribute  for  the  element  type. 

2.  The  NAME  Parameter 

The  NAME  Parameter  must  be  a  valid  UNIX  pathname  (unless  it  is 
the  empty  string).  If  any  directory  in  the  pathname  is  inaccessible, 
USE-ERROR  or  NAME-ERROR  is  raised. 

The  UNIX  names  ’’stdin”,  ’’stdout”,  and  ’’stderr”,  can  be  used  with 
TEXT-IO.OPEN.  No  physical  opening  of  the  external  file  is  performed 
and  the  Ada  file  will  be  associated  with  the  already  open  external  file. 
These  names  have  no  significance  for  other  I/O  packages. 
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Temporary  files(NAME  =  null  string)  are  created  using  tmpname(3) 
and  will  be  deleted  when  CLOSED.  Abnormal  program  termination 
may  leave  temporary  files  in  existence.  The  name  function  will  return 
the  full  name  of  temporary  file  when  it  exists. 

3.  The  Form  Parameter 


The  Form  Parameter,  as  described  below,  is  applicable  to  DIRECTJO, 
SEQUENTIALJO  and  TEXTJO  operations.  The  value  of  the  Form 
Parameter  for  Ada  I/O  shall  be  a  character  sting.  The  value  of  the 
character  string  shall  be  a  series  of  fields  separated  by  commas.  Each 
field  shall  consist  of  optional  separators,  followed  by  a  field  name  iden¬ 
tifier,  followed  by  optional  separators,  followed  by  "  =  followed  by 
optional  separators,  followed  by  a  field  value,  followed  by  optional  sep¬ 
arators.  The  allowed  values  for  the  field  names  and  the  corresponding 
field  values  are  described  below.  All  field  names  and  field  values  are 
case-insensitive. 

The  following  BNF  describes  the  syntax  of  the  FORM  parameter: 


form 

fields 


rights  : : 

access  : ; 

access.underscor  : : 

append  : 

blocking  ; 

terminal, input  :: 

fifo  :  : 

posix_file_de script or 


[field  {,  field}*] 
rights  I  append  I  blocking  I 
terminal, input  1  fifo  I 
posix,f ile, descriptor 
OWNER  I  GROUP  |  WORLD  => 

READ  I  WRITE  I  EXECUTE  I  NONE 
,READ  I  , WRITE  |  ,EXECUTE  I  ,N0NE 
APPEND  =>  YES  I  NO 
BLOCKING  =>  TASKS  |  PROGRAM 
TERMINAL,INPUT  =>  LINES  I  CHARACTERS 
FIFO  =>  YES  I  NO 
::=  POSIX,FILE,DESCRIPTOR  =>  2 


The  Form  Parameter  is  used  to  control  the  following  : 

(a)  File  ownership: 

Access  rights  to  a  file  is  controlled  by  the  following  field  names 
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’’OWNER”,  ’’GROUP”  and  ”WORLD”.  The  field  values  are 
’’READ”,  ’’WRITE”,  ’’EXECUTE”  and  ’’NONE”  or  any  com¬ 
bination  of  the  previously  listed  values  separated  by  underscores. 
The  access  rights  field  names  are  applicable  to  TEXT  JO,  DI¬ 
RECT  JO  and  SEQUENTIALJO.  The  default  value  is  OWNER 
=  >  READ.WRITE,  GROUP  =>  READ.WRITE  and  WORLD 
=  >  READ.WRITE.  The  actual  actual  access  rights  on  a  created 
file  will  be  the  default  value  subtracted  the  value  of  the  environ¬ 
ment  variable  umask. 

Example 

To  make  a  file  readable  and  writable  by  the  owner  only,  the  form 
Parameter  should  look  something  like  this: 

"Owner  =>read_write ,  World=>  none,  Group=>none" 

If  one  or  more  of  the  field  names  are  missing  the  default  value  is 
used.  The  permission  field  is  evaluated  in  left-to-right  order.  .An 
ambiguity  may  arise  with  a  Form  Parameter  of  the  following: 

" Owner=>Read_Exe cut e_None .Write .Read" 

In  this  instance,  using  the  left-to-right  evaluation  order,  the  "None” 
field  will  essentially  reset  the  permissions  to  none  and  this  e.xample 
would  have  the  access  rights  WRITE  and  RE.AD. 

(b)  Appending  to  a  file: 

Appending  to  a  file  is  achieved  by  using  field  name  ’’APPEND” 
and  one  of  the  two  field  values  ”YES”  or  ”NO”.  The  default 
value  is  ”NO”.  ’’Append”  is  allowed  with  both  TEXTJO  and 
SEQUENTIALJO.  The  effect  of  appending  to  a  file  that  all  out¬ 
put  to  that  file  is  written  to  the  end  of  the  named  external  file. 
This  field  may  only  be  used  with  the  ’’OPEN”  operation,  using 
the  field  name  ’’APPEND”  in  connection  with  a  ’’CREATE”  op¬ 
eration  shall  raise  USEJIRROR.  Furthermore,  a  USEJIRROR  is 
raised  if  the  specified  file  is  a  terminal  device  or  another  device. 

Example 

To  append  to  a  file,  one  would  write: 
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"Append  =>  Yes" 

(c)  Blocking  vs.  non-blocking  I/O: 

The  blocking  field  name  is  ’’Blocking”  and  the  field  valuet  are 
’’TASKS”  and  ’’PROGRAM”.  The  default  value  is  ’’PROGRAM”. 
’’Blockings > Tasks”  causes  the  calling  task,  but  no  others,  to  vait 
for  the  completion  of  an  I/O  operation.  ”Blocking=> program” 
causes  all  tasks  within  the  program  to  wait  for  the  completion 
of  the  I/O  operation.  The  blocking  mechanism  is  applicable  to 
TEXTJO,  DIRECTJO  and  SEQUENTIAL_IO.  UNIX  does  not 
allow  the  support  of  ”BLOCKING=>TASKS”  currently. 

(d)  How  characters  are  read  from  the  keyboard: 

The  field  name  is  ’’TERMINAL-INPUT”  and  field  value  is  ei¬ 
ther  ’’LINES”  or  ’’CHARACTERS”.  The  effect  of  the  field  value 
’’TerminaUnput  =>  Characters”  is  that  characters  are  read  in  a 
noncanonical  fashion  with  Minimum-count=l,  meaning  one  char¬ 
acter  at  a  time=:0.0  corresponding  so  that  the  read  operation  is 
not  satisfied  until  Minimum-Count  characters  are  received.  If 
field  value  ’’LINES”  is  used,  the  characters  are  read  one  line  at 
a  time  in  canonical  mode.  The  default  value  is  Lines.  ’’TERMI- 
NALJNPUT”  has  effect  if  the  specified  file  is  not  already  open  or 
if  the  file  is  not  open  on  a  terminal.  It  is  permitted  for  the  same 
terminal  device  to  be  opened  for  input  u.  ooth  modes  as  separate 
Ada  file  objects.  In  this  case,  no  user  input  characters  shall  be 
read  from  the  input  device  without  an  explicit  input  operation  on 
one  of  the  file  objects.  The  ’’TERMINAL-INPUT”  mechanism  is 
only  applicable  to  TEXTJO. 

(e)  Creation  of  FIFO  files: 

The  field  name  is  ’’FIFO”  and  the  field  value  is  either  ”YES”  or 
”NO”.  ’’FIFO  =>  YES”  means  that  the  file  shall  be  a  named 
FH'O  file.  The  default  value  is  ”NO”.  For  use  with  TEXTJO, 
the  ’’FIFO”  field  is  only  allowed  with  the  CREATE  operation. 
If  used  in  connection  with  an  OPEN  operation,  USE-ERROR  i 
raised. 

For  SEQUENTIALJO,  the  FIFO  mechanism  is  applicable  for 
both  the  CREATE  and  OPEN  operation. 
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In  connection  with  SEQUENTIALJO,  an  additional  field  name 
”0_NDELAY”  is  used.  The  field  values  allowed  for  ’’O.NDELAY” 
are  ”YES”  and  "NO”.  Default  is  ”NO”.  The  ’’OJ^DELAY”  field 
name  is  provided  to  allow  waiting  or  immediate  return.  If,  for 
example,  the  following  form  parameter  is  given: 

■'FIF0=>Yes,  Q_NDELAY=>Yes‘' 

then  waiting  is  performed  until  completion  of  the  operation.  The 
”0_Ndelay”  field  name  only  has  meaning  in  connection  with  the 
FIFO  facility  and  otherwise  ignored. 

(f)  Access  to  open  POSIX  files: 

The  field  nanie  is  ”POSIX_FileJDescriptor”.  The  field  value  is 
the  character  string  ”2”  which  denotes  the  stderr  file.  Any  other 
field  value  will  result  in  USE-ERROR  being  raised.  The  NAME 
parameter  provides  the  value  which  will  be  returned  by  subsequent 
usage  of  the  NAME  function.  The  operation  does  not  change  the 
state  of  the  file.  During  the  period  that  the  Ada  file  is  open,  the 
result  of  any  file  operations  on  the  file  descriptor  are  undefined. 
Note  that  this  is  a  method  to  make  stderr  accessible  from  an  Ada 
program. 

4,  File  Access 

The  following  guidelines  should  be  observed  when  performing  file  I/O 
operations: 

•  .At  a  given  instant,  any  number  of  files  in  an  .Ada  program  can  be 
associated  with  corresponding  external  files. 

•  When  sharing  fileo  between  programs,  it  is  the  responsibility  of 
the  programmer  to  determine  the  effects  of  sharing  files. 

•  The  RESET  and  OPEN  operations  to  files  with  mode  Ol'T.FILE 
will  empty  the  contents  of  the  file  in  SEQUENTIALJO  and  TEXT  JO. 

•  Files  can  be  interchanged  between  SEQUENTIALJO  and  DI¬ 
RECT  JO  without  any  special  operations  if  the  files  are  of  the 
same  object  type. 
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9.3  Buffering 

The  Ada  1/ O  system  provides  buffering  in  addition  to  the  buffering  provided 
by  UNIX.  The  Ada  TEXT_IO  packages  will  flush  all  output  to  the  operating 
system  under  the  following  circumstances: 

1.  The  device  is  a  terminal  device  and  an  end  of  line,  end  of  page,  or  end 
of  file  has  occurred. 

2.  The  device  is  a  terminal  device  and  the  same  Ada  program  makes  an 
Ada  TEXT-IO  input  request  or  another  file  object  representing  the 
same  device. 

9.4  Package  IO_EXCEPTIONS 

The  specification  of  package  IO_EXCEPTIONS: 

Package  lO.EXCEPTIONS  is 

--  The  order  of  the  following  declarations  must  NOT  be  changed: 

STATUS.ERROR  :  exception; 

M0DE_ERR0R  :  exception; 

NAME.ERROR  :  exception; 

USE_ERR0R  ;  exception; 

DEVICE.ERROR  :  exception; 

END_ERR0R  :  exception; 

DATA_ERROR  :  exception; 

LAYOUT.ERROR  •  '’xception; 

end  I0_EXCEPTI0NS; 

9.5  Sequential  Input-Output 

The  implementation  omits  type  checking  for  DATA_ERROR,  in  case  the 
element  type  is  of  an  unconstrained  type,  .ARM  14.2.2(4),  i.e.; 
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...f  :  FILE.TYPE 
type  et  is  1 . . 100; 

type  eat  is  array (  et  range  <>  )  of  integer; 

X  :  eat(  1. .2  ); 

Y  :  eat(  1. .4  ); 

--  write  X,  Y: 

write(  f,  X):  write(  f,  Y);  reset(  f,  IN_FILE) ; 

—  read  X  into  Y  and  Y  into  X: 
read(  f,  Y);  read(  f,  X); 

This  will  give  undefined  values  in  the  last  2  elements  of  Y,  and  not 
DATA.ERROR. 

1.  Specification  of  the  Package  Sequential  10 


with  BASIC.IO.TYPES; 
with  10. EXCEPTIONS; 
generic 

type  ELEMENT.TYPE  is  private; 
package  SEQUENTIAL.IO  is 

type  FILE.TYPE  is  limited  private; 
type  FILE.MODE  is  (IN.FILE,  OUT.FILE) ; 

--  File  management 


procedure 

CREATE (FILE 

in 

out 

FILE.TYPE; 

MODE 

in 

FILE.MODE  ;=  OUT.FILE; 

NAME 

in 

STRING  := 

FORM 

in 

STRING  := 

procedure 

OPEN 

(FILE 

in 

out 

FILE.TYPE; 

MODE 

in 

FILE.MODE; 

NAME 

in 

STRING ; 

FORM 

in 

STRING  :=  ""); 

procedure 

CLOSE 

(FILE 

in 

out 

FILE.TYPE) : 
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procedure  DELETE(FILE 
procedure  RESET  (FILE 
MODE 

procedure  RESET  (FILE 
function  MODE  (FILE 
function  NAME  (FILE 
function  FORM  (FILE 
function  IS_OPEN(FILE 


in  out  FILE.TYPE); 
in  out  FILE.TYPE; 
in  FILE.MODE) ; 
in  out  FILE.TYPE); 
in  FILE.TYPE)  return  FILE.MODE; 
in  FILE.TYPE)  return  STRING; 
in  FILE.TYPE)  return  STRING; 
in  FILE.TYPE)  return  BOOLEAN; 


—  input  and  output  operations 

procedure  READ  (FILE  :  in  FILE.TYPE; 

ITEM  :  out  ELEMENT.TYPE) ; 

procedure  WRITE  (FILE  :  in  FILE.TYPE; 

ITEM  ;  in  ELEMENT.TYPE); 

function  END.OF_FILE(FILE  :  in  FILE.TYPE)  return  BOOLEAN; 


exceptions 

STATUS.ERROR 

MODE.ERROR 

NAME.ERROR 

USE.ERROR 

DEVICE.ERROR 

END. ERROR 

DATA.ERROR 


exception 

exception 

exception 

exception 

exception 

exception 

exception 


renames 

renames 

renames 

renames 

renames 

renames 

renames 


lO.EXCEPTIONS .STATUS.ERROR; 
lO.EXCEPTIONS . MODE.ERROR ; 
lO.EXCEPTIONS . NAME.ERROR ; 
lO.EXCEPTIONS . USE.ERROR ; 
lO.EXCEPTIONS . DEVICE.ERROR ; 
lO.EXCEPTIONS . END.ERROR ; 

10. EXCEPTIONS. DATA.ERROR; 


private 

type  FILE.TYPE  is  new  BASIC. lO.TYPES .FILE.TYPE ; 


end  SEQUENTIAL. 10; 


9.6  Direct  Input-Output 

The  implementation  omits  type  checking  for  DATA.ERROR.  in  case  the 
element  type  is  of  an  unconstrained  type. 

1.  Specification  of  the  Package  Direct  10 
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with  BASIC.IO.TYPES; 
with  lO.EXCEPTIONS; 
generic 

type  ELEMENT.TYPE  is  private ; 
package  DIRECT.IO  is 

type  FILE.TYPE  is  limited  private; 

type  FILE.MODE  is  (IN.FILE,  INOUT.FILE,  OUT.FILE) ; 

type  COUNT  is  range  0. . INTEGER 'LAST; 

subtype  POSITIVE.COUNT  is  COUNT  range  1 . .COUNT 'LAST; 

—  File  management 

procedure  CREATE(FILE  :  in  out  FILE_TYPE; 

MODE  :  in  FILE.MODE  :=  INOUT.FILE; 

NAME  :  in  STRING  := 

FORM  :  in  STRING  := 

procedure  OPEN  (FILE  :  in  out  FILE_TYPE; 

MODE  :  in  FILE.MODE; 

NAME  ;  in  STRING; 

FORM  :  in  STRING  := 

procedure  CLOSE  (FILE  :  in  out  FILE.TYPE); 

procedure  DELETE(FILE  :  in  out  FILE.TYPE) ; 
procedure  RESET  (FILE  :  in  out  FILE.TYPE; 

MODE  :  in  FILE.MODE); 

procedure  RESET  (FILE  :  in  out  FILE.TYPE); 

function  MODE  (FILE  :  in  FILE.TYPE)  return  FILE.MODE; 

function  NAME  (FILE  :  in  FILE.TYPE)  return  STRING; 

function  FORM  (FILE  :  in  FILE.TYPE)  return  STRING; 

function  IS.OPEN(FILE  :  in  FILE.TYPE)  return  BOOLEAN; 

—  input  and  output  operations 

procedure  READ  (FILE  :  in  FILE.TYPE; 

ITEM  :  out  ELEMENT.TYPE; 

FROM  :  in  POSITIVE.COUNT) ; 

procedure  READ  (FILE  :  in  FILE.TYPE; 

ITEM  ;  out  ELEMENT.TYPE); 

procedure  WRITE  (FILE  :  in  FILE.TYPE; 
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ITEM  :  in  ELEMENT.TYPE ; 

TO  :  in  POSITIVE.COUNT) ; 

procedure  WRITE  (FILE  :  in  FILE.TYPE; 

ITEM  :  in  ELEMENT.TYPE) ; 

procedure  SET_INDEX(FILE  :  in  FILE.TYPE; 

TO  :  in  POSITIVE.COUNT) ; 

function  INDEX(FILE  :  in  FILE.TYPE)  return  POSITIVE.COUNT; 
function  SIZE  (FILE  :  in  FILE.TYPE)  return  COUNT; 
function  END.OF.FILE(FILE  :  in  FILE.TYPE)  return  BOOLEAN; 


exceptions 
STATUS. ERROR 

:  exception 

renames 

MODE.ERROR 

:  exception 

renaunes 

NAME.ERROR 

:  exception 

renames 

USE.ERROR 

:  exception 

renaimes 

DEVICE.ERROR 

:  exception 

renames 

END.ERROR 

:  exception 

renaones 

DATA.ERROR 

:  exception 

renames 

lO.EXCPTIONS . STATUS. ERROR ; 
lO.EXCPTIONS.MODE.ERROR; 
lO.EXCPTIONS. NAME.ERROR; 
lO.EXCPTIONS .USE. ERROR; 
lO.EXCPTIONS . DEVICE.ERROR ; 
lO.EXCPTIONS . END.ERROR ; 
lO.EXCPTIONS. DATA.ERROR; 


private 

type  FILE.TYPE  is  new  BASIC.IO.TYPES. FILE.TYPE; 
end  DIRECT.IO; 


9.7  Specification  of  the  Package  Text.IO 

with  BASIC.IO.TYPES; 
with  10. EXCEPTIONS; 
package  TEXT.IO  is 

type  FILE.TYPE  is  limited  private; 

type  FILE.MODE  is  (IN. FILE,  OUT.FILE) ; 

type  COUNT  is  range  0  ..  INTEGER'LAST ; 

subtype  POSITIVE.COUNT  is  COUNT  range  1  ..  COUNT 'LAST; 

UNBOUNDED:  constant  COUNT :=  0;  --  line  and  page  length 

--  max.  size  of  an  integer  output  field  2U....U 

subtype  FIELD  is  INTEGER  range  0  ..  35; 
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subtype  NUMBER.BASE  is  INTEGER  range  2  ..  16; 
type  TYPE.SET  is  (LOWER.CASE,  UPPER.CASE) ; 

—  File  Management 

procedure  CREATE  (FILE  :  in  out  FILE_TYPE; 

MODE  :  in  FILE.MODE  :=  OUT.FILE; 

NAME  :  in  STRING  := 

FORM  :  in  STRING  := 

procedure  OPEN  (FILE  ;  in  out  FILE_TYPE; 

MODE  :  in  FILE.MODE; 

NAME  :  in  STRING; 

FORM  :  in  STRING  := 

procedure  CLOSE  (FILE  :  in  out  FILE.TYPE); 

procedure  DELETE  (FILE  :  in  out  FILE.TYPE) ; 

procedure  RESET  (FILE  :  in  out  FILE_TYPE; 

MODE  :  in  FILE.MODE); 

procedure  RESET  (FILE  :  in  out  FILE.TYPE) ; 

function  MODE  (FILE  :  in  FILE.TYPE)  return  FILE.MODE; 

function  NAME  (FILE  :  in  FILE.TYPE)  return  STRING; 

function  FORM  (FILE  :  in  FILE.TYPE)  return  STRING; 

function  IS.OPEN(FILE  :  in  FILE.TYPE)  return  BOOLEAN; 

—  Control  of  default  input  and  output  files 
procedure  SET.INPUT  (FILE  :  in  FILE.TYPE); 

procedure  SET.OUTPUT  (FILE  :  in  FILE.TYPE); 

function  STANDARD.INPUT  return  FILE.TYPE; 

function  STANDARD. OUTPUT  return  FILE.TYPE; 

function  CURRENT. INPUT  return  FILE.TYPE; 

function  CURRENT. OUTPUT  return  FILE.TYPE; 


—  specification  of  line  and  page 
procedure  SET.LINE.LENGTH  (FILE 

TO 

procedure  SET.LINE.LENGTH  (TO 
procedure  SET.PAGE.LENGTH  (FILE 

TO 

procedure  SET.PAGE.LENGTH  (TO 


lengths 
in  FILE.TYPE; 
in  COUNT); 
in  COUNT); 
in  FILE.TYPE; 
in  COUNT); 
in  COUNT) ; 
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function  LINE.LENGTH  (FILE  :  in  FILE.TYPE)  return  COUNT 

function  LINE.LENGTH  return  COUNT 

function  PAGE.LENGTH  (FILE  :  in  FILE.TYPE)  return  COUNT 

function  PAGE.LENGTH  return  COUNT 

—  Column,  Line,  and  Page  Control 

procedure  NEW.LINE  (FILE  :  in  FILE.TYPE; 

SPACING  :  in  POSITIVE.COUNT  :=  1); 
procedure  NEW.LINE  (SPACING  :  in  POSITIVE.COUNT  :=  1); 

procedure  SKIP.LINE  (FILE  :  in  FILE.TYPE; 

SPACING  ;  in  POSITIVE.COUNT  :=  1); 
procedure  SKIP.LINE  (SPACING  :  in  POSITIVE.COUNT  :=  1); 


function 

END.OF.LINE 

(FILE  : 

function 

END.OF.LINE 

procedure 

NEW.PAGE 

(FILE  : 

procedure 

NEW.PAGE 

procedure 

SKIP.PAGE 

(FILE  : 

procedure 

SKIP.PAGE 

function 

END.OF.PAGE 

(FILE  : 

function 

END.OF.PAGE 

function 

END.OF.FILE 

(FILE  : 

function 

END.OF.FILE 

procedure 

SET.COL 

(FILE  : 
TO  : 

procedure 

SET.COL 

(TO  : 

procedure 

SET.LINE 

(FILE  : 
TO  : 

procedure 

SET.LINE 

(TO 

function 

COL 

(FILE  : 

function 

COL 

function 

LINE 

(FILE  : 

function 

LINE 

function 

PAGE 

(FILE  : 

function 

PAGE 

in  FILE.TYPE)  return  BOOLEAN; 

return  BOOLEAN; 

in  FILE.TYPE): 

> 

in  FILE.TYPE); 

» 

in  FILE.TYPE)  return  BOOLEAN; 

return  BOOLEAN; 
in  FILE.TYPE)  return  BOOLEAN; 

return  BOOLEAN; 

in  FILE.TYPE; 
in  POSITIVE.COUNT); 
in  POSITIVE.COUNT): 
in  FILE.TYPE; 
in  POSITIVE.COUNT); 
in  POSITIVE.COUNT); 
in  FILE.TYPE) 

return  POSITIVE.COUNT; 
return  POSITIVE.COUNT; 
in  FILE.TYPE) 

return  POSITIVE.COUNT; 
return  POSITIVE.COUNT; 
in  FILE.TYPE) 

return  POSITIVE.COUNT; 
return  POSITIVE.COUNT; 
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—  Character  Input -Output 


procedure 

GET 

(FILE 

:  in 

FILE. 

.TYPE; 

ITEM 

out  CHARACTER); 

procedure 

GET 

(ITEM 

out  CHARACTER); 

procedure 

PUT 

(FILE 

:  in 

FILE.TYPE; 

ITEM 

:  in 

CHARACTER) ; 

procedure 

PUT 

(ITEM 

:  in 

CHARACTER) ; 

—  String 

Input -Output 

procedure 

GET 

(FILE 

:  in 

FILE. 

.TYPE; 

ITEM 

out  STRING); 

procedure 

GET 

(ITEM 

out  STRING); 

procedure 

PUT 

(FILE 

:  in 

FILE.TYPE; 

ITEM 

:  in 

STRING); 

procedure 

PUT 

(ITEM 

:  in 

STRING); 

procedure 

GET. 

.LINE 

(FILE 

:  in 

FILE.TYPE; 

ITEM 

:  out 

STRING ; 

LAST 

:  out 

NATURAL) ; 

procedure 

GET. 

.LINE 

(ITEM 

:  out 

STRING ; 

LAST 

:  out 

NATURAL) ; 

procedure 

PUT. 

.LINE 

(FILE 

:  in 

FILE.TYPE; 

ITEM 

:  in 

STRING) ; 

procedure 

PUT. 

.LINE 

(ITEM 

:  in 

STRING) ; 

—  Generic  Package  for  Input-Output  of  Integer  Types 
generic 

type  NUM  is  range  <> ; 
package  INTEGER.IO  is 

DEFAULT. WIDTH  :  FIELD  :=  NUM 'WIDTH; 

DEFAULT.BASE  :  NUMBER.BASE  ;=  10; 

procedure  GET  (FILE  :  in  FILE.TYPE; 

ITEM  out  NUM; 

WIDTH  :  in  FIELD  ;=  0); 
procedure  GET  (ITEM  out  NUM; 

WIDTH  :  in  FIELD  :=  0); 
procedure  PUT  (FILE  :  in  FILE.TYPE; 
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ITEM 

:  in 

WIDTH 

:  in 

BASE 

:  in 

procedure 

PUT 

(ITEM 

WIDTH 

:  in 

:  in 

BASE 

:  in 

procedure 

GET 

(FROM 

ITEM 

:  in 

LAST 

procedure 

PUT 

(TO 

ITEM  :  in 
BASE  :  in 


end  INTEGER.IO; 


NUM; 

FIELD  :=  DEFAULT.WIDTH; 
NUMBER.BASE  :=  DEFAULT.BASE) ; 

NUM; 

FIELD  :=  DEFAULT.WIDTH: 
NUMBER.BASE  ;=  DEFAULT.BASE) ; 

STRING; 
out  NUM; 
out  POSITIVE); 
out  STRING; 

NUM; 

NUMBER.BASE  :=  DEFAULT.BASE); 


—  Generic  Packages  for  Input-Output  of  Real  Types 
generic 

type  NUM  is  digits  <>; 
package  FLOAT. 10  is 

DEFAULT.FORE  :  FIELD  :=  2; 

LEFAULT.AFT  :  FIELD  :=  NUM’digits  -  1; 
DEFAULT. EXP  :  FIELD  :=  3; 

procedure  GET  (FILE  :  in  FILE.TYPE; 

ITEM  out  NUM; 

WIDTH  :  in  FIELD  :=  0); 


procedure 

GET 

(ITEM 

1 

out 

MUM; 

WIDTH 

:  in 

FIELD  :=  0): 

procedure 

PUT 

(FILE  : 

in 

FILE. 

TYPE; 

ITEM  : 

in 

NUM; 

FORE  : 

in 

FIELD 

:=  DEFAULT.FORE; 

AFT  : 

in 

FIELD 

:=  DEFAULT. AFT; 

EXP  : 

in 

FIELD 

;=  DEFAULT.EXP) : 

procedure 

PUT 

(ITEM  : 

in 

NUM; 

FORE  : 

in 

FIELD 

;=  DEFAULT.FORE, 

AFT  : 

in 

FIELD 

:=  DEFAULT. AFT; 

EXP 

in 

FIELD 

:=  DEFAULT.EXP); 

procedure 

GET 

(FROM  : 

in 

STRING ; 

ITEM  : 

out  NUM; 
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LAST 

out  POSITIVE); 

procedure  PUT 

(TO 

out  STRING; 

ITEM 

in 

NUM; 

AFT 

in 

FIELD  :=  DEFAULT. AFT; 

EXP 

in 

FIELD  :=  DEFAULT.EXP) ; 

end  FLOAT.IO; 

generic 

type  MUM  is  delta  <>; 

package  FIXED.IO 

is 

DEFAULT.FORE 

FIELD 

=  MUM ‘FORE; 

DEFAULT.AFT 

FIELD 

=  MUM’AFT; 

DEFAULT.EXP 

FIELD 

=  0 

procedure  GET 

(FILE 

:  in  FILE.TYPE; 

ITEM 

t 

out  NUM; 

WIDTH 

:  in  FIELD  :=  0); 

procedure  GET 

(ITEM 

1 

out  NUM; 

WIDTH 

:  in  FIELD  ;=  0); 

procedure  PUT 

(FILE 

in 

FILE.TYPE; 

ITEM 

in 

NUM; 

FORE 

in 

FIELD  :=  DEFAULT.FORE; 

AFT 

in 

FIELD  :=  DEFAULT. AFT; 

EXP 

in 

FIELD  :=  DEFAULT.EXP); 

procedure  PUT 

(ITEM 

in 

NUM; 

FORE 

in 

FIELD  :=  DEFAULT.FORE; 

AFT 

in 

FIELD  :=  DEFAULT.AFT; 

EXP 

in 

FIELD  :=  DEFAULT.EXP); 

procedure  GET 

(FROM 

in 

STRING ; 

ITEM 

out  NUM; 

LAST 

out  POSITIVE); 

procedure  PUT 

(TO 

out  STRING; 

ITEM 

in 

NUM; 

AFT 

in 

FIELD  :=  DEFAULT.AFT; 

EXP 

in 

FIELD  :=  DEFAULT.EXP); 

end  FIXED ..10; 


Generic  Package  for  Input-Output  of  Enumeration  Types 
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generic 

type  ENUM  is  (<>); 
package  ENUMERATION.IO  is 

DEFAULT.WIDTH  :  FIELD  :=  0; 

DEFAULT.SETTING  :  TYPE.SET  :=  UPPER.CASE; 

procedure  GET  (FILE  :  in  FILE.TYPE; 

ITEM  :  out  ENUM); 

procedure  GET  (ITEM  :  out  ENUM); 

procedure  PUT  (FILE  :  in  FILE.TYPE; 

ITEM  :  in  ENUM; 

WIDTH  :  in  FIELD  :=  DEFAULT.WIDTH; 

SET  :  in  TYPE.SET  :=  DEFAULT.SETTING) ; 

procedure  PUT  (ITEM  :  in  ENUM; 

WIDTH  :  in  FIELD  :=  DEFAULT.WIDTH; 

SET  :  in  TYPE.SET  :=  DEFAULT.SETTING) ; 

procedure  GET  (FROM  :  in  STRING; 

ITEM  :  out  ENUM; 

LAST  :  out  POSITIVE); 

procedure  PUT  (TO  :  out  STRING; 

ITEM  :  in  ENUM; 

SET  :  in  TYPE.SET  :=  DEFAULT.SETTING); 

end  ENUMERATION.IO; 

--  Exceptions 

STATUS. ERROR  :  exception  renames  10. EXCEPTIONS .STATUS.ERROR; 
MODE.ERROR  :  exception  renames  lO.EXCEPTIONS .MODE. ERROR; 
NAME.ERROR  :  exception  renames  lO.EXCEPTIONS .NAME.ERROR ; 
USE.ERROR  :  exception  renames  lO.EXCEPTIONS .USE.ERROR; 

DEVICE.ERROR  :  exception  renames  lO.EXCEPTIONS .DEVICE.ERROR; 
END. ERROR  :  exception  renames  lO.EXCEPTIONS .END.ERROR; 

DATA. ERROR  :  exception  renames  lO.EXCEPTIONS .DATA. ERROR; 

LAYOUT.ERROR  :  exception  renames  lO.EXCEPTIONS .LA YOUT.ERROR; 
private 

type  FILE.BLOCK.TYPE  is  new  BASIC. lO.TYPES .FILE.TYPE; 
type  FILE.OBJECT.TYPE  is  record 
IS.OPEN  :  BOOLEAN  :=  FALSE; 

FILE.BLOCK  :  FILE.BLOCK.TYPE; 
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end  record; 

type  FILE.TYPE  is  access  FILE_OBJECT_TYPE: 
end  TEXT.IO; 


9.8  Low  Level  Input-Output 

The  package  LOW_LEVELJO  is  empty. 

9.9  Package  TERMINAL 

The  specification  of  package  TERMINAL: 

with  COMMON.DEFS; 
use  COMMON.DEFS; 

Package  TERMINAL  is 

procedure  SET_CURS0R(R0W,  COL  :  in  INTEGER); 
procedure  IN_CHARACTER(CH  :  out  CHARACTER); 

procedure  IN.INTEGER  (I  :  out  INTEGER); 

procedure  IN.LINE  (T  :  out  TERMINAL.LINE) ; 

procedure  OUT_CHARACTER(CH  :  in  CHARACTER); 

procedure  OUT.INTEGER  (I  :  in  INTEGER); 

procedure  OUT_INTEGER_F(I ,  H  :  in  INTEGER); 

procedure  OUT.LINE  (L  :  in  STRING); 

procedure  OUT.STRING  (S  :  in  STRING); 

procedure  0UT_NL; 
procedure  0UT_FF; 
procedure  FLUSH; 

procedure  OPEN_LOG_FILE(FILE_NAME  :  in  STRING); 
procedure  CL0SE_L0G_FILE; 
end  TERMINAL; 


